The most serious PHP warning in years
The PHP project has issued an emergency security advisory urging all users to update immediately after the discovery of two critical vulnerabilities that can allow unauthenticated remote code execution — the most severe class of web flaw, because it lets an attacker run commands on a server without needing any account or password (PHP.net). The fixes were released on 21 October in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP security team had taken the unusual step of pre-announcing the release on 20 October, warning that both flaws are rated CVSS 9.2 (PHP.net).
PHP powers a huge share of the world’s websites, including WordPress and the millions of sites built on it, which is why a core flaw in the language itself — rather than in any single app or plugin — is such a significant event.
What the two flaws actually are
The first, CVE-2026-109618, is an “RCE via OOM corruption”: PHP’s out-of-memory handling can interrupt the engine while internal request data is only partially initialised, and the cleanup that follows may then treat that invalid data as valid (PHP.net). The second, CVE-2026-109619, is an “RCE via stale global state”: internal state belonging to one request can survive after its memory has been freed, and a later request handled by the same worker may use that stale state before normal initialisation resets it (PHP.net).
According to the advisory, every kind of PHP installation serving web requests is at risk — PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed — with the risk considered highest for mod_php, where a demonstrated exploit can be triggered by an unauthenticated request before any application code even runs (PHP.net).
“No complete mitigations — updating is the only safe choice”
The PHP team’s language is unusually blunt. Each of the four release announcements states plainly that there are no complete mitigations and that updating is the only safe choice (PHP.net). The advisory does list partial stopgaps for people who genuinely cannot patch straight away — for example, removing PHP’s controllable memory limit and lowering post_max_size reduces exposure to the out-of-memory path, and disabling session upload progress blocks the confirmed session paths of the second flaw — but it stresses that these measures “do not make an installation safe” (PHP.net).
Owners of older versions face the hardest decision. PHP 8.1 and older no longer receive updates from the PHP project at all, although some Linux distributions and long-term-support vendors provide backported fixes, and the security team has published minimal source backports for PHP 7.4, 8.0 and 8.1 for people building from source (PHP.net). The team also notes that PHP 8.2 reaches end of life on 31 December 2026, after which it will receive no further security fixes — a deadline every site still running it should now be planning around (PHP.net).
The story is still developing. On 23 October, php.net published a follow-up advisory about a related session-handling weakness and said a full advisory for a further issue, CVE-2026-115560, will arrive with the next regular release (PHP.net).
If you cannot patch today, the stopgaps are specific
For administrators who cannot update immediately, the advisory’s interim measures are unusually precise — and unusually honest about their limits. Against the out-of-memory flaw, it recommends removing PHP’s controllable memory limit (set in a way applications cannot override, such as php_admin_value in an FPM pool), keeping post_max_size low, and enforcing request-size limits at the web server or proxy — while warning not to substitute process memory limits such as RLIMIT_AS, which can themselves cause the allocation failure that triggers the bug (PHP.net). Against the stale-state flaw, it recommends disabling session upload progress at server level and restarting every worker, fixing attacker-reachable fatal errors and timeouts, and — on PHP 8.5 — disabling fatal error backtraces (PHP.net). Even followed completely, the team repeats, these steps only reduce exposure to specific attack paths. They buy time; they do not close the hole.
What this means if you run a website
First, check your PHP version today — and know this is a hosting-level fix. Your version is shown in your host’s control panel or your CMS’s site-health screen. A WordPress or plugin update does not change the PHP version itself; the update has to happen at server level, by you in the hosting panel or by your hosting provider.
Second, do not be reassured by stopgaps. The PHP team itself says configuration tweaks only narrow the attack paths. If your host cannot move you to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor-backported equivalent), that is a reason to escalate — or to change hosts.
Third, the long tail is the real danger. Flaws like these are most damaging months later, on forgotten sites that were never updated. If you run a PHP site — as we noted in our coverage of how AI is changing everyday software, the modern web quietly depends on layers most owners never look at — this is the weekend to look.