A leak, not a disclosure, started the clock
The two flaws, now informally bundled as php2shell, surfaced on October 20 through a leak rather than the coordinated disclosure process PHP normally follows. CVE-2026-109618 is an out-of-memory condition during request setup that leaves data partially initialized, which later gets treated as valid during cleanup and opens a path to code execution. CVE-2026-109619 is a use-after-free: PHP retains request-specific state after freeing the memory, and a later request on the same worker can touch that stale state, leading to unauthenticated memory disclosure and remote code execution at the privilege level of the web worker itself. Both describe memory-handling errors deep in PHP's request lifecycle, the kind of flaw that is hard to spot in code review and trivial to weaponize once someone finds it.
Both carry a CVSS v4.0 score of 9.2, among the highest ratings PHP's ecosystem has seen in years. PHP moved fast once the leak forced its hand, shipping fixed releases 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21 at roughly 9:30 a.m. ET, less than 24 hours after the leak became public. That is a credible emergency-response timeline by vendor standards, and PHP's maintainers deserve credit for compressing a normal disclosure cycle into a single working day. The problem for defenders is structural: a leak hands attackers the same head start it hands the vendor, and in this case attackers used every minute of it, probing for exposed systems before most security teams had even read the advisory.
The gap between patch and probe was hours, not days
Security firm watchTowr tracked the exploitation timeline in near real time, and the numbers are worth sitting with. At 11:26 UTC on October 21, it reported no observed exploitation anywhere. By 14:19 UTC, the same day, it was reporting active exploitation attempts against both CVEs across the internet. That is roughly a three-hour window from patch release to confirmed attack traffic, well inside the time most enterprises need just to convene a change-advisory board, let alone test and roll out a fix across every PHP-serving system they operate across regions and business units.
Huntress, watching its own partner base, had not confirmed successful in-the-wild exploitation on its monitored systems as of 4:30 p.m. ET that day, while noting other researchers were already reporting attacks emerging elsewhere on the open internet. Most organizations sit in exactly that window right now: already actively targeted, with no confirmed breach yet, and the clock running fastest against whichever one patches last. That is an uncomfortable place to operate from, and it is where unpatched systems will stay until someone closes the gap.
Cloudflare's default rules didn't hold either
Cloudflare enabled firewall rules for the php2shell CVEs by default at 03:02 UTC on October 21, ahead of many customers even knowing the flaws existed, and ahead of PHP's own official patch landing later that morning. On paper, that should have bought meaningful breathing room for every site sitting behind Cloudflare's network. In practice, it bought hours, not safety. Cloudflare confirmed it saw attack traffic against its own customers, and that attackers deliberately adjusted their payloads to route around those default rules once their first attempts ran into them.
This matters because it undercuts a pattern CTOs rely on more than they should: treating a cloud WAF's default ruleset as sufficient cover until internal patching catches up on its own schedule. Here, the adversary treated the WAF as one more obstacle to iterate past rather than a wall to stop at, and iterated past it within the same day the rule went live. A WAF rule bought time. Only the actual patch bought closure, and attackers adapted to the rule faster than most security teams could even confirm the rule was holding.
The exposure is wider than anyone's asset inventory
PHP's own guidance is blunt: all PHP installations serving web requests are at risk, spanning PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP, and LiteSpeed. mod_php carries the highest severity because an unauthenticated request can trigger the exploit before any application code even runs, meaning the vulnerability sits beneath whatever web application firewall, authentication layer, or business logic a team assumes is protecting the application layer above it. No amount of input validation in your own codebase closes a hole that opens before your code ever executes.
The harder problem is PHP 8.1 and earlier, which are past end of life and receive no official patches, though minimal source backports exist for 7.4, 8.0, and 8.1 for teams willing to build from source. That version tail runs deep inside vendor-bundled software: WordPress, Drupal, Joomla, and Magento installs, along with control panels and CMS plugins that most IT inventories were never built to track in the first place. For organizations running legacy e-commerce or content platforms acquired through years of mergers, the honest fix list is longer than a single patch cycle, and some systems will have no clean fix available at all for months.
What a 24-hour response actually looks like
Huntress's practical guidance is worth treating as a checklist to run this week, not background reading to file away. Inventory every PHP install across the estate, including the ones bundled inside vendor software and CMS platforms that teams tend to forget are running PHP underneath their own branding. Patch internet-facing systems first, since that is where the probing is concentrated right now, and only then move to internal systems. For end-of-life versions with no patch path, apply the stopgap configuration change Huntress recommends, disabling session.upload_progress in php.ini and restarting services, while separately planning the actual version upgrade those systems need.
Equally important is detection, because patching alone does not tell you whether you were already hit before you patched. Huntress recommends watching for PHP worker processes, php-fpm, php-cgi, httpd, apache2, spawning shells, interpreters, or download utilities, since that is the behavioral signature of successful exploitation regardless of which specific CVE triggered it. If compromise is suspected, isolate the server and preserve web and PHP logs immediately, before any patch deployment or service restart overwrites the evidence a post-incident investigation will need to reconstruct what happened.
The decision this forces on CTOs
The lasting signal from php2shell is the compression of the entire exploitation lifecycle into a single business day: leak, patch, probe, adapt, all completed before most change-advisory boards would even have scheduled a meeting to discuss it. Any enterprise still running a weekly or monthly patch cadence for internet-facing infrastructure is implicitly betting that the next leaked zero-day will be kinder about timing than this one was, and that bet is getting worse odds every quarter as leaks and exploit development both accelerate.
The decision worth making this week is whether your organization can patch an unplanned, critical, internet-facing vulnerability within hours rather than days, across every system that happens to run PHP somewhere in its stack, including the vendor software nobody remembers is built on it. Answering that honestly means testing it, not assuming it. If the real answer turns out to be no, this incident is the concrete example to cite when asking for the budget and organizational authority to close that gap before the next leak starts the clock running again.
-6.png?w=1024)
