Two Critical PHP Flaws Can Let Strangers Run Code on Web Servers. Wikipedia and the BBC Took Pages Offline.

Patches exist for four branches of PHP, the language behind 69 percent of the websites whose server software is known. For the branches running roughly 48 percent of those sites, there is no official patched release at all. That is the part of this week’s PHP emergency the “update now” headlines skip.

The emergency itself is real. On Wednesday the PHP project published security releases for two critical vulnerabilities that can allow unauthenticated remote code execution, and Wikimedia said it had deliberately taken many of its supporting services offline until they could be patched. Pages on the BBC went dark. 4chan and Something Awful pulled themselves off the network to wait for a fix.

Here is what the flaws are, in the project’s own words. CVE-2026-109618 is “RCE via OOM corruption”: out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and cleanup then treats the invalid data as valid. CVE-2026-109619 is “RCE via stale global state”: request data survives after its memory is freed, and a later request handled by the same worker can use it.

The project lists who is at risk as “all PHP installations serving web requests, including PHP-FPM, Apache with modphp, php-cgi, FrankenPHP and LiteSpeed.” It calls the risk highest for modphp, where it has a demonstrated exploit in which an unauthenticated request triggers the attack “before any application code runs.”

That last phrase is why this is not a plugin story. The flaw sits underneath WordPress, Drupal and every other PHP application, so patching the application does nothing. SOCRadar’s write-up says updating WordPress alone provides no protection, because the runtime itself has to change.

Now the number nobody has put on the page. We took W3Techs’ PHP version split, which puts PHP 8 at 65.3 percent of PHP sites, PHP 7 at 26.9, PHP 5 at 7.7 and PHP 4 at 0.1, and multiplied the PHP 8 share by its minor-version breakdown (8.3 at 34.9 percent, 8.2 at 27.6, 8.1 at 15.1, 8.4 at 12.1, 8.0 at 5.8, 8.5 at 4.5). Both pages were read on October 23. The project’s own list of fixed releases decides which rows count.

Two cautions on our own arithmetic. W3Techs counts websites, not servers, so a hosting company running ten thousand sites on one old PHP counts ten thousand times. And it only sees sites whose language it can detect. The direction does not change under either caveat: about half of PHP’s footprint is on branches the project has stopped updating. The advisory says so plainly: “PHP 8.1 and older no longer receive updates from the PHP project,” though “some distributions and LTS vendors provide backported fixes.”

Even the 51.7 percent is less comfortable than it looks. PHP 8.2, which carries 18 percent of PHP sites, reaches end of life on December 31, about ten weeks from now. The branch that was patched on Wednesday is already on the clock.

So what is the “update now” advice worth to someone on a shared host? Very little, because they cannot update anything. They are waiting for a provider to do it, and the provider decides which backport, if any, they get.

The workarounds are partial, and the project says so. Setting session.upload_progress.enabled=0 and restarting every worker blunts the second flaw, and lowering request-size limits reduces exposure to the first, but “only an update is a complete solution” and these measures “do not make an installation safe.” Reports on whether anyone is already exploiting the flaws conflict. NBC reported that CISA had not observed exploitation when it published, while SOCRadar cites Amazon threat intelligence attempts starting October 17, four days before the patch.

We think the advice has been written for the half of the web that can follow it. Wikipedia and the BBC can switch a service off for a day and absorb the cost. A clinic, a school, a local news site or a small shop running an old PHP on a cheap host cannot, and the UK’s National Cyber Security Centre told them exactly that, in effect: where immediate remediation is not feasible, consider taking the system offline. That is an honest sentence, and it is not what most of the coverage led with.

The practical line is simple. Ask your host or your developer, in writing, which PHP version your site runs and whether it carries a fix for CVE-2026-109618 and CVE-2026-109619. A host that cannot answer by the end of the week should be treated as unpatched. If the answer is 8.1 or older, the project’s own advice is to move to a supported branch, and with 8.2 expiring on New Year’s Eve, “supported” should mean 8.3 or newer.