Two Pre-Auth PHP Flaws Put 70% of the Web on the Clock

Roughly 70 percent of the web needed an engine swap this morning, and most of it didn't know it owned the car. PHP shipped emergency fixes for two critical flaws in the language runtime itself — CVE-2026-109618 and CVE-2026-109619, collectively nicknamed PHP2Shell — that let an attacker with no account, no credentials and no phishing email execute code on a vulnerable server. Working exploits exist. Exploit attempts are already hitting sensors. And because the bugs live in PHP rather than in WordPress, Drupal, Joomla or Magento, a completely patched application sitting on an unpatched runtime is still lunch.

The scope is the story. According to Krebs on Security, Censys recently counted approximately 2.58 million internet-facing hosts and 54.9 million web properties running PHP, and researchers at Wiz say every PHP version released in the last decade is affected by at least one of the two bugs. The vulnerable branches go back to PHP 5.4. The fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Everything else is a decision about how much risk you're willing to finance.

A decade asleep, a day on fire: the timeline

Start with the uncomfortable part: the flaws are old. Wiz's researchers wrote that the underlying bugs had been present for decades, and that proving exploitability took an exceptionally complex chain of steps — until, in their words, frontier AI models reduced that barrier, "turning a longstanding flaw into an exploit." Read that twice. The expensive part of weaponising ancient bugs just got cheaper, permanently. Whatever you think of AI hype, the cost curve on the attacker's side of the ledger moved, and it isn't moving back. We've seen what dormant bugs look like when they finally surface — the 37-year-old OpenBSD shared-memory bug was the same lesson with a smaller blast radius.

Discovery credit goes to researchers at Wiz, Calif and OpenAI, who reported the flaws and coordinated with the PHP team on patch verification and disclosure ahead of publication. OpenAI called it one of the most impactful security issues in recent memory given PHP's reach. Then the schedule broke: according to The Hacker News, details leaked on October 20, a day ahead of a planned October 22 disclosure. If you've ever run a coordinated disclosure, you know what a leak does to a patch window — it converts days into hours and hands the stopwatch to anyone watching.

By 3:02 a.m. UTC on October 21, Cloudflare had deployed web application firewall rules to block attack traffic — and said it had already detected exploitation attempts targeting the bugs, which can cause denial of service, remote code execution and data exposure. Around 14:00 UTC the same day, PHP published the fixed releases and its advisory, stating plainly that only a full update completely protects a server. Also on October 21, governments started pulling plugs: Finnish government services went offline, as did sites belonging to the Dutch parliament, Dutch cybersecurity authorities and the Dutch data protection regulator; privacy group noyb temporarily withdrew its site too, The Register reported. Reuters, via Krebs, said government websites in Europe and elsewhere dropped as a precaution.

Meanwhile the offensive side got to work. Jake Knott, head of threat intelligence at watchTowr, told The Register that its sensors were already seeing in-the-wild exploitation attempts with what he described as vibecoded proof-of-concepts sporting a variety of 'php2shell' User-Agents. His assessment: "Whilst nobody has been successful to date, we don't expect that will last long." Wiz expects the endgame to be mass exploitation installing web shells — rented rooms in your server with the locks changed.

What does the sequence tell defenders? Three things. The leak compressed your window, so yesterday was the right time to patch. The WAF vendors moved before the patches existed, which tells you where the cheap hours are. And the governments that went dark did the math I'll do below: for some estates, downtime is cheaper than the alternative.

Why mod_php servers go to the front of the queue

Not all PHP deployments carry the same risk, and pretending they do wastes your most expensive resource tonight: attention. The PHP project says every installation serving web requests is potentially affected — PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP, LiteSpeed — but it singles out mod_php as the highest risk, with a demonstrated exploit in which one unauthenticated request fires the attack before any application code executes. Your WAF, your login page, your expensive zero-trust gateway: all downstream of a bug that goes off upstream of all of them.

PHP-FPM is in better shape but not safe shape. PHP's own analysis supports that FPM is susceptible to one of the flaws while no complete FPM exploit has been demonstrated for it; the second flaw was shown reaching code execution on both mod_php and FPM, though the FPM path depends on an operation inside the running application. And here's the sleeper cost nobody's pricing: an attacker can read memory out of the PHP worker process — passwords, authentication tokens, API keys, certificates from other requests — without achieving code execution at all, and the researchers demonstrated that against applications they didn't control. Even a 'failed' attack can walk out with your secrets. Budget for credential rotation accordingly.

The WAF buys hours. The config tweaks buy less. The patch buys the fix.

Now the money question the board will actually ask: what do the cheaper options get us? Cloudflare's 3:02 a.m. ruleset is genuinely valuable — it's a turnstile that slows the crowd while you fix the door. But the PHP advisory is blunt that only updating is a complete fix, and everything else reduces exposure to specific attack paths without making a server safe. The partial mitigations are worth deploying tonight if you can't patch tonight, as long as nobody in your organisation files them under 'done':

; Stopgap for CVE-2026-109618 — reduces exposure, does NOT fix
memory_limit = -1          ; set centrally so applications can't override it
post_max_size = 8M         ; keep low; also enforce request-size limits at the web server/proxy
; Do NOT rely on RLIMIT_AS or RLIMIT_DATA — PHP warns they can trigger the same vulnerable path
; Stopgap for CVE-2026-109619 — blocks confirmed session paths only
session.upload_progress.enabled = 0   ; then restart every worker
; On PHP 8.5 additionally:
fatal_error_backtraces = 0

Session upload progress is on by default and can reach session handling before PHP finishes setting up a request, which is why it sits in one confirmed attack path for CVE-2026-109619 — and why that setting, which circulated as 'the workaround' before release, does nothing at all for CVE-2026-109618. PHP core developer Gina Peter Banyard put it more economically than any analyst could:

"The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much," wrote PHP core developer Gina Peter Banyard, replying to a suggestion that a configuration setting might suffice.

So the honest hierarchy is: full upgrade first, WAF rules as a seatbelt while you drive to the garage, config stopgaps as a prayer, and isolation for anything you can't patch and can't afford to lose. CERT-EU, which rated both flaws 9.2 on the CVSS scale, said it before the patches even landed: where immediate patching isn't feasible, isolate internet-facing applications from public networks. That's the governments' play, and for a tax portal or a parliament site with no revenue meter running, it's rational. For an e-commerce site on a Thursday, the arithmetic is uglier — which is exactly why you do the arithmetic now rather than during incident response.

Where the real cost hides: inventory, not the patch

The patch itself is nearly free. Linux distributions and long-term-support vendors received fixes in advance — Ubuntu has already shipped updated packages, per the SANS Internet Storm Center's tracker cited by Krebs — and a distribution package may carry the fix under an old-looking version number. As Debian advises, check the package changelog for the CVE, not the version string, before you panic or, worse, before you relax. The PHP project has also published source backports for PHP 7.4, 8.0 and 8.1, which no longer receive updates, for those building from source or waiting on a vendor. PHP 8.2 itself goes end of life on December 31, so if this drill hurt, you've had a preview of your next budget conversation.

The expensive part is finding everything. Huntress senior principal security researcher John Hammond nailed it: "The number of places you have to go looking to identify vulnerable PHP versions gets very big, very fast." PHP hides inside shared hosting platforms, control panels, appliances and software that doesn't advertise its runtime. Updating WordPress or Laravel does nothing for the engine underneath — the runtime comes from the server package, the host or the container image. And after updating, you must restart Apache, PHP-FPM and every long-running worker, then re-check your memory settings: the fix introduces a new hard memory limit that, when reached, ends the process without running shutdown handlers. Test that against what your applications actually need before production finds out for you.

Wiz compared the pair to Log4Shell, and for once I'll allow the comparison — not because the exploitation is identical but because the embedding problem is. PHP runs across clouds, hosting providers, CDNs and millions of independently managed servers, and Wiz expects organisations to be patching this for some time. Translation for the CFO: this isn't a patch Tuesday, it's an asset-inventory quarter you didn't budget for.

My call

Act now, and spend in this order: find every PHP runtime you own, patch mod_php first, restart everything, then chase the FPM and container stragglers with WAF rules and the ini stopgaps as cover — never as substitutes. If you run something genuinely unpatchable and genuinely high-stakes, the Dutch parliament just showed you the honest answer. And when the board asks whether the AI angle changes anything, tell them the truth: it changes the future, not tonight. Tonight is a patch night.