Critical PHP Security Update: Four Questions to Ask Your Web Host This Week

On Tuesday 20 October 2026, the PHP project gave advance warning of an emergency security release. The next day it shipped one, fixing two flaws that allow a stranger to run their own code on a web server without logging in to anything ^[1]. The same day, Ireland's National Cyber Security Centre published an advisory telling organisations to find every PHP installation they run and patch the internet-facing ones first ^[2].

If your business website runs on WordPress, it runs on PHP. So does every other WordPress site on the web, which is why this week mattered well beyond the server rooms.

This guide is for the owner, not the server administrator. Your job this week is not to patch anything yourself. It is to verify that whoever runs your server has done it, and to recognise a good answer when you ask. I will cover what happened, why your dashboard stays quiet, the four questions worth sending to your host, whether to take your site offline, and the limits of what any patch can fix.

What Happened This Week, in Plain Terms

PHP is the programming language WordPress is written in. Every time someone opens a page on your site, the server runs PHP to assemble that page from your content, your theme and your plugins. You never see it. Think of it as the engine under the bonnet.

The two flaws, CVE-2026-109618 and CVE-2026-109619, sit in the part of PHP that handles incoming requests ^[1]. According to the PHP project, there is a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs ^[1]. Both carry a severity score of 9.2 on a scale that tops out at 10.

Why no password was needed

For a business owner, unauthenticated means exactly what it sounds like. No password, no login form, no plugin weakness, no careless member of staff. A single crafted request to the server could be enough, and because it happens before WordPress loads, any security plugin you have installed inside WordPress never gets a look at it.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ^[1]. Older releases on those branches are vulnerable. Anything below 8.2 gets no fix from the PHP project at all.

Who is affected

Ireland's NCSC is blunt about scope: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php and LiteSpeed ^[2]. The PHP project rates mod_php setups as the highest risk ^[1]. That is a ranking of danger, not a list of the safe.

Two more dates matter. On 23 October the PHP project published a further, lower-risk advisory about a related piece of code, with a fix scheduled for its next regular release ^[1]. And PHP 8.2 stops receiving security updates altogether on 31 December 2026 ^[5]. This story has at least one more chapter.

Why Your WordPress Dashboard Will Not Warn You

WordPress.org was clear: no WordPress update is required or planned, because the flaws affect any server running PHP applications, not WordPress itself ^[4]. No red badge will appear next to Updates. WordPress will not email you either. Your plugins will report themselves up to date, and they will be right.

That silence is the dangerous part. Most owners have been trained, correctly, to watch the dashboard. This week the flaw lived one layer below it, in the server software layer you never see, and the only people who could fix it were whoever operates your server.

Consider what an unnoticed compromise usually looks like. Nothing breaks on Wednesday. The site keeps loading and enquiries keep arriving while a small file sits on the server, waiting. Weeks later Google starts showing a warning beside your listing, or a customer forwards you a phishing page hosted on your own domain, and by the time anyone noticed, the trail back to this week has gone cold.

What Site Health can tell you

WordPress does give you one window into this. Under Tools, then Site Health, then the Info tab, the Server section shows your PHP version ^[4]. That number is the most useful thing you can bring to a conversation with your host, and the checklist near the end of this guide shows you how to read it.

Four Questions to Ask Your Host This Week

WordPress.org's own advice is to check with your host, noting that hosts may already be updating PHP and adding firewall rules, but that you should confirm rather than assume ^[4]. Good advice. Vague in practice. These four questions turn a nervous email into something a host has to answer properly.

Question	A reassuring answer	A worrying answer
Which PHP version is my site on, and when was it updated?	A specific version at or above the fixed release, with a date	We are looking into it, with no version or date
Were the PHP processes restarted after the update?	Yes, and the running version was verified	Confusion about the question
Will my version still get security fixes after 31 December 2026?	Yes, or a planned move to a supported branch	No plan, or a version below 8.2
Have you checked for signs of compromise since 21 October?	Yes, a malware scan has run, with results	Silence, or nothing has been reported

1. Which PHP version is my site running, and when was it updated?

You want a number and a date. "We patch regularly" is a policy, not an answer. If your host says 8.3.36 or 8.4.27, compare it against the fixed releases above.

One honest complication. Some hosts install PHP from operating system packages that backport security fixes into an older-looking version number. A lower number is therefore a question to put to your host, not proof of a hole. A good host can tell you in one sentence which applies. One that cannot is telling you something too.

2. Were the PHP processes restarted after the update?

This sounds technical. It is the question I would most want answered. Installing an updated package puts new code on the disk, but the PHP processes already running in memory keep serving pages until they are restarted. The PHP project's interim guidance tells administrators to restart all workers after changing a setting ^[1], and the same principle applies to an update.

In plain terms, a new lock delivered to your shop does nothing while it sits in the box by the door. A host with a real operations process verifies the version that is actually running in production, not the version that was downloaded.

3. Will my version still get security fixes after 31 December 2026?

Getting through this week is the first test. The second arrives in just over two months. PHP 8.2's security support ends on 31 December 2026 ^[5], after which the next flaw like this one will not be fixed for 8.2 at all, and Ireland's NCSC already tells organisations to identify end-of-life PHP and isolate it where mitigations cannot be applied ^[2].

The backlog is not small. W3Techs reports that roughly a third of websites using PHP still run version 7 or older ^[6], though its figures depend on what servers announce about themselves, so treat that as an order of magnitude rather than a precise count. Those sites received no fix this week.

Moving to a newer PHP version is normally the host's job, but it can surface a dependency conflict with an old plugin or theme. The safe sequence is a backup, a test in a staging environment, then deploy to production with a rollback ready.

4. Have you checked for signs of compromise since 21 October?

Patching closes the door. It says nothing about who walked through it before it closed. The UK's NCSC advises checking for signs of compromise and backdoors where systems could not be updated immediately ^[3]. For a small business site, that means a malware scan of the files on your server and a look at the Users screen in WordPress for administrator accounts you did not create.

Should You Take Your Website Offline?

Some of the official advice this week sounded alarming to a business owner. The UK's NCSC said organisations "should consider taking the system offline until it can be fully mitigated" ^[3], and WordPress.org noted that several national cyber security agencies gave similar advice ^[4].

Read it in context. That advice is written for organisations running their own servers that cannot apply the update or the interim mitigations. If your host has patched and confirmed the running version, taking your site down protects nothing and costs you customers.

A composite case: the late-night callout

Consider a typical scenario. A locksmith in Longford hears the warning on the radio on Wednesday morning and wonders whether to pull the website. Most emergency lockout calls come from people searching on a phone while standing outside a locked front door, often late at night. A site that is offline does not take those calls. The next name in the search results does.

So the sensible order runs like this. Email your host, get the version and the restart confirmed, and only consider going offline if you cannot get a straight answer and you know the server is running an unpatched or end-of-life version. In that case a short, planned outage is cheaper than a compromised server.

What Managed Hosting Should Mean in a Week Like This

Strip away the marketing and a properly managed host should do six things in an event like this without being asked:

• Watch for advisories and pre-announcements, so preparation starts before the fix ships
• Apply the patched PHP release across every server, starting with those facing the internet
• Restart the running PHP processes and verify the version actually serving pages
• Scan for signs of compromise, because patching cannot undo what happened before it
• Keep recent, restorable backups in case something did get in
• Answer a customer's email with a version number, in plain English, from a person

That is the standard. Measure any host against it, including the one I work for.

How Web60 approaches it

On Web60, PHP is part of the managed stack rather than a setting the owner is expected to babysit. Sites run on the WordOps stack with Nginx and PHP-FPM on SmartHost's sovereign Irish cloud, with server-level security hardening, fail2ban intrusion prevention and automatic malware scanning sitting underneath WordPress. Nightly backups with one-click restore, plus automatic snapshots before updates and restores, mean there is always a recent point to fall back to. In practice, a week like this one should cost you an email at most, not an evening. The full picture of Web60's managed Irish hosting stack is laid out on one page.

I will be straight about one point. PHP-FPM is not the setup the PHP project rated highest risk this week, but Ireland's NCSC lists it among the affected configurations ^[2]. Lower risk is not no risk. The protection comes from patching and verifying, not from the choice of setup.

When you want to ask the four questions above, the answer comes from an Irish-based support team, real people rather than an outsourced queue. If you would rather not be chasing a version number from your current provider, Web60 builds a WordPress site in under a minute for €60 a year, and the free migration service moves an existing site across.

Where another setup genuinely suits better

A managed platform is not right for everyone. If your business runs custom server software alongside its website and employs a systems administrator who patched every server by Wednesday evening, an unmanaged cloud server gives you control over timing and configuration that a managed platform deliberately takes away. That is a real trade-off, and some businesses should make it. Most owner-operated businesses do not have that person on the payroll, and that gap is the whole point of managed hosting.

Cheaper hosting is not automatically the problem either. If your budget host answered within a day with the right version number and confirmation of a restart, they did their job this week. Price was never the test. The answer was.

What Patching Cannot Fix

A patch is a lock on the door from today onwards. It has limits, and you should know them before a customer asks.

• It does not remove anything already planted. Advance notice of this release went out the day before the fix shipped ^[1], and details of serious flaws often circulate before a patch reaches every server. Anything installed in that window survives the update, which is why the fourth question exists.
• It does not cover your plugins. This week's flaw lived below WordPress. Next month's may live inside an abandoned plugin installed years ago. Server patching and plugin updates are separate jobs, and the second is partly yours.
• It is probably not the last patch. The 23 October advisory has its fix scheduled for the next regular release ^[1]. Expect at least one more update, and expect a good host to apply it with the same urgency.
• A backup restores files, not certainty. If a compromise is found, restoring an earlier backup can return the site to a clean state, but you lose whatever changed since, and the hole must be closed first or the attacker simply walks back in.

For the wider picture of how server, plugins and backups fit together, the complete guide to WordPress security and backups covers the plugin and recovery side in more depth.

How to Verify Your PHP Version in Four Steps

1. Log in. Open your WordPress dashboard with an administrator account.
2. Verify. Go to Tools, then Site Health, then the Info tab, and expand the Server section to find the PHP version.
3. Compare. Check the number against 8.2.35, 8.3.36, 8.4.27 or 8.5.12 for your branch, and treat anything below 8.2 as end of life.
4. Escalate. Email your host with the number you found and the four questions above, then keep their reply on file.

Conclusion

Weeks like this one are when you find out what your hosting arrangement actually includes. Nobody expected you to read a PHP security advisory, and nobody should expect you to apply one. What you can do in the next ten minutes is open Site Health, write down one number, and send one email. The reply will tell you more about your host than any feature list. If it comes back quickly, with a version, a restart and a scan, you can close the laptop and get back to running your business.

Frequently Asked Questions

Do I need to update WordPress because of the PHP security flaw?

No. WordPress.org confirmed that no WordPress update is required, because the flaws are in PHP itself, the language the server uses to run WordPress. The fix has to be applied on the server, which on most hosting plans means your host does it. Keep WordPress, plugins and themes updated as normal anyway.

How do I check which PHP version my website uses?

In your WordPress dashboard, go to Tools, then Site Health, open the Info tab and expand the Server section. The PHP version is listed there. Your hosting control panel may also show it.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Versions older than 8.2 receive no fix from the PHP project. Some hosts use operating system packages with backported fixes, so if your number is lower, ask your host to confirm rather than assuming the worst.

Should I take my website offline until my host patches PHP?

Usually not. Official advice to consider going offline is aimed at organisations running their own servers that cannot apply the update. If your host confirms the patched version is running, keep your site up. Consider a planned outage only if you cannot get an answer and you know the server is unpatched or end of life.

What happens when PHP 8.2 reaches end of life?

After 31 December 2026, PHP 8.2 receives no further security fixes from the PHP project, so a future flaw like this one would stay open on any server still running it. Ask your host now about moving to 8.3 or later, and test the move in a staging environment first in case an old plugin conflicts.

Can a security plugin protect my site from this kind of PHP flaw?

Not reliably. The PHP project says the attack can trigger before any application code runs, and WordPress security plugins are application code. Hosts may add firewall rules as a stopgap, but the PHP project is clear that updating PHP is the only complete fix.

Sources