PHP Spotted One PHP2Shell Flaw in 2024, and Attackers Struck Four Days Before the Fix Shipped

Most emergency patches arrive with a simple story: researchers found a bug, the vendor fixed it, now go update. PHP2Shell does not fit that shape. One of its two flaws was glimpsed inside PHP's own audit work two years ago. The fix was scheduled for a coordinated release on October 22, leaked on October 20, and shipped a day early on October 21. Attackers had already tried it four days before that. And the runtime it lives in powers websites, government portals and, it turns out, firewalls, which means the hardest question for most IT teams this week is not how to patch PHP but where PHP actually is.

Two Bugs, a Decade Old, With No Login Required

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are both rated 9.2 under CVSS v4.0 and let an unauthenticated attacker run code on the server. watchTowr's technical FAQ describes the first as out-of-memory corruption: PHP runs out of memory partway through setting up a request, leaving half-built internal data that cleanup code then trusts. The second is stale global state, where data from one request outlives its memory and the next request on the same worker acts on the leftovers. Every PHP installation serving web requests is in scope, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, and PHP rates mod_php the highest risk because the attack can succeed before the application's own code ever runs.

According to The Hacker News, the flaws were reported by Wiz Research, Calif and OpenAI's Codex Security team, reach back to PHP 5.4, and had been in the code for more than a decade. Researchers also showed that attackers can read PHP worker memory without achieving code execution, exposing passwords, tokens, API keys and certificates belonging to other users' requests. Wiz told Help Net Security the findings rank among the most severe ever discovered in PHP, and that frontier AI models substantially lowered the barrier to turning the flaw into a working exploit.

A Known Bug, a Stalled Fix and a Leaked Date

The uncomfortable part came from PHP itself. In a blog post published hours after the release, the PHP Foundation said a core developer had spotted the memory-handling bug in 2024 while fixing a separate issue raised by PHP's first external security audit. Nobody found a concrete attack path at the time. The security team drafted competing fixes: one broke backward compatibility, one added a denial-of-service risk, and one forced changes on thousands of third-party extensions. Working by consensus, a small team stalled and restarted for months. The Foundation called the delay "a structural failure," caused by both its decision process and its lack of resources, and says it is moving security decisions to majority voting after setting up an Ecosystem Security Team in May and hiring two more engineers.

The report that finally forced the issue arrived on August 11 from researcher Ryan A, and OpenAI independently reported the same root cause that day. Calif had begun auditing PHP under OpenAI's Patch the Planet program on July 30. Coordinated disclosure was set for October 22. Around 15:00 UTC on October 20 the CVE identifiers began circulating online with a wrong 10.0 severity score; that evening Calif mistakenly posted a video of its proof of concept, and Chainguard published patched images more than six hours before the official release. PHP pulled the release forward to October 21. The Foundation also noted it has published 15 CVEs since early July while working through more than 100 reports that were invalid or duplicates.

None of that sequencing helped defenders as much as it should have, because someone was already probing. Sophos's advisory cites an Amazon Threat Intelligence observation of an exploitation attempt on October 17 and recommends reviewing logs from August 1 onward, the month the flaws were reported. watchTowr recorded exploitation in the wild on release day, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26, telling organizations still on PHP 8.1 or earlier, or unable to patch, to take those systems offline until they can.

The PHP You Cannot See Is the PHP That Stays Exposed

The scale is the reason operators reached for the off switch. BleepingComputer reports roughly 5.1 million PHP hosts exposed online, about 3.8 million of them with at least one port open to attack. iTWire lists cyber.gov.au and government sites in France, Finland, Denmark and the Netherlands among those pulled offline, along with Wikipedia systems and the Port of Rotterdam, and BambooHR took its service down in three countries as a precaution.

The longer tail is PHP that no one counts as PHP. By October 22, Palo Alto Networks had confirmed that every PAN-OS and Panorama version was affected with no fixed release yet, while Fortinet was checking 12 products and Cisco 31 products and cloud services. Forensics specialist Hal Pomeranz summed up the problem as "so many embedded installations out there that will never be patched." Even patched servers need care: distribution packages can carry the fix under old-looking version numbers, so the changelog, not the version string, is the evidence, and workers must be restarted before the fix takes effect. Sophos warns that in-process protection such as RASP may not stop CVE-2026-109618 on mod_php, and PHP states that no configuration change fully mitigates either.

What to Do This Week

• Inventory by process, not by asset tag. Look for running php, php-fpm and php-cgi processes and confirm versions from the binary, as Sophos advises, and include PHP bundled in appliances, hosted services and vendor products.
• Patch internet-facing mod_php first. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, verify the CVE in the package changelog, and restart every PHP worker so the fix actually loads.
• Treat 8.1 and older as unpatched. Source backports exist for 7.4, 8.0 and 8.1, but nothing exists below that. Follow CISA's advice and take anything that cannot be upgraded offline or behind network-layer authentication.
• Assume exposure from August. Review logs for unusual multipart POSTs, PHP_SESSION_UPLOAD_PROGRESS, memory-limit errors, segfaults and unexpected child processes, and rotate secrets that passed through exposed workers.
• Chase your vendors in writing. Ask every appliance and SaaS supplier whether PHP sits in their stack and when a fix ships, starting with firewalls and VPN gateways.
• Plan the 8.2 exit now. PHP 8.2 reaches end of life on December 31, 2026, so anything just patched onto 8.2 joins the unsupported list in nine weeks.

PHP2Shell will be remembered for the leak and the scramble, but the more durable lesson is the two-year gap between a bug being seen and a fix shipping, in a project the Foundation says rests on a small group of funded developers and volunteers. AI-assisted research is now finding old flaws in foundational code faster than those teams can agree how to fix them. The organizations that came through this week best were the ones that already knew where their PHP was.