PHP2Shell: The Website Flaw Your Plugins Can’t Fix

We heard about this one from a software vendor’s newsletter, the day before the fix came out. Not from a dashboard, not from our hosting provider, not from WordPress. If that email had gone to spam, we would have found out later than the people scanning for it.

That is the real lesson here, and it applies to your website too.

What happened

On October 20, the PHP project posted an unusual advance warning: a security release was coming the next day for two vulnerabilities rated 9.2 out of 10 on the CVSS scale. On October 21 at 14:00 UTC, it shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with a blunt headline: “Critical remote code execution vulnerabilities, update now.”

“Remote code execution” means an attacker can make your server run their own commands. Both flaws can be triggered by an anonymous web request, with no password and no account. PHP says the advisory applies to every PHP installation that serves web pages, and rates the risk highest on servers that run PHP inside Apache with mod_php, where “an unauthenticated request can trigger the attack before any application code runs.”

That last part matters. The attack happens before WordPress, before your plugins, before your security plugin gets a chance to look at the request.

Why your plugins cannot fix this

Most small business websites are WordPress, and WordPress is written in PHP. PHP is the engine underneath. Your site’s code, themes and plugins sit on top of it.

When a plugin has a flaw, you update the plugin. This is different. The flaw is in the engine, so the engine has to be replaced. Cloudflare put it plainly in its own write-up: “updating website code or a plugin(s) alone does not fix these vulnerabilities.”

Who replaces the engine depends on how your site is hosted:

• Shared or managed hosting (most small businesses): your host updates PHP. You cannot do it yourself, and you should not have to.
• A server or VPS you rent and manage: you are the host. Nobody else is going to do it.
• Your web designer set it up and moved on: find out which of the two above it is, today.

Is anyone actually attacking this?

Yes, attempts started almost immediately. The security firm watchTowr reported on October 21 that exploitation had been observed in the wild through its network of honeypots, which are decoy servers set up to catch attackers. Cloudflare said it observed attack traffic targeting its customers, and that attackers were changing their payloads to get around its filters.

At the time of writing, CISA had not yet added either flaw to its catalog of vulnerabilities known to be exploited, and we have seen no public confirmation of a successful break-in. That is the window you want to be patched in, not the one after.

If your site is behind Cloudflare

There is some good news. Cloudflare says that since October 21 at 3:02 UTC, about nine hours before the flaws went public, customers using its firewall have been “protected by default”, including on the free plan. Free customers do not need to switch anything on.

Two limits, though. The filter only sees traffic that actually passes through Cloudflare, so anyone who can reach your server directly goes around it. And Cloudflare itself says customers “should patch their PHP repos even with WAF protections.” A filter blocks the attacks it recognises. The patch removes the flaw.

The version number trap

You might expect to check this by looking for “8.4.27” or “8.3.36”. Sometimes that works. Sometimes it badly misleads you.

Linux distributions often patch the version they ship instead of moving to a new one. Ubuntu’s fix for its 24.04 release, published the same day, is php8.3 version 8.3.6-0ubuntu0.24.04.13. It is patched, and it says “8.3.6”. Ubuntu 22.04 even received a fix for PHP 8.1, a version the PHP project itself no longer updates.

So a number that looks old is not proof you are exposed, and a number that looks new is not proof you are safe. The only reliable answer comes from whoever installed it.

What we did on our own servers

We put a temporary mitigation from PHP’s advisory in place within the first hours, then waited for the patched packages. The popular download server that many Ubuntu servers use for current PHP versions returned errors for most of the afternoon. The maintainer pointed to an alternate mirror, and our servers were on the fixed version the same evening, tested first on a copy of the site.

We mention it because “the patch is out” and “the patch is installed” can be hours apart even when someone is actively working on it. If nobody is working on it, they can be months apart.

What to ask your web host this week

1. “Have you patched PHP against CVE-2026-109618 and CVE-2026-109619, and on what date?” Use the CVE numbers. They turn a vague question into one with a yes or no answer.

2. “Which PHP version does my site run, and is it still supported?” You can see the version yourself in WordPress under Tools, then Site Health, then the Info tab, under Server. If it is 8.1 or older, ask how they are covering it, because the PHP project is not.

3. “Was PHP restarted after the update?” A patch on disk does nothing until the running PHP is restarted. A good host will find this question obvious. That is fine.

If you cannot get a clear answer in writing within a day or two, that is your answer.

Where to start

Open your WordPress dashboard, check the PHP version under Site Health, and send your host the three questions above. It takes ten minutes.

Then ask the bigger question: who at your company would have heard about this if the newsletter had never arrived? Knowing what you run, watching for fixes and installing them on a schedule is what patch and vulnerability management actually is. It is the same problem as an Office version that quietly stops getting fixes, one layer down. If nobody owns it today, talk to us.

Sources: PHP security advisory, Cloudflare, Ubuntu USN-8948-1, watchTowr.