PHP Patches Two Critical RCE Flaws That Were Already Under Attack

PHP recently shipped emergency releases on October 21, fixing two critical vulnerabilities that allow unauthenticated remote code execution, and Amazon says someone tried to exploit them four days before the patches existed.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 carry fixes for CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0 and nicknamed php2shell. Both are memory-safety failures in the request lifecycle, one in out-of-memory handling and one in state that outlives the memory backing it, and Sansec reports they are present in every unpatched PHP since 5.4. The announcement is blunt about the options: "There are no complete mitigations; updating is the only safe choice."

Exposure varies by how PHP is served, and the advisories are careful about what has actually been proven. Apache mod_php carries confirmed remote code execution for both, validated "over HTTP against mod_php with default PHP input and memory limits." For PHP-FPM the session lifecycle case was validated, but on the out-of-memory bug the advisory states that "no complete FPM exploit has been demonstrated for this SAPI." FrankenPHP is described as likely susceptible on source analysis alone.

Attackers arrived before the patch did. Amazon Threat Intelligence found an exploitation attempt dating to October 17 in MadPot telemetry, originating from "an IP address associated with a commercial anonymization network," and told customers to investigate "from at least starting on October 17th." Cloudflare deployed WAF rules at 03:02 UTC on October 21, roughly nine hours ahead of release.

The coordinated disclosure had already collapsed. In its own account, the PHP Foundation says the CVE identifiers began circulating two days early, that a researcher "mistakenly published a video" showing a proof of concept, and that "Chainguard unilaterally broke the embargo and published built images containing the fix." The consequence, it writes, was that "any attacker could now study the fix in binary form while every other PHP user was still waiting for the release." Chainguard’s published policy, last updated a month before the incident, allows it to shorten disclosure timelines when "a vulnerability is discovered to be under active exploitation."

Some operators stopped serving rather than wait. On r/selfhosted, commenter iamShorteh described shutting down:

I’ve taken all of my websites offline (turned off apache2). Somebody leaked the step by step for RCE on twitter a few hours ago. Not going to risk sitting around another 5-6 hours until the hotfix lands.

The Dutch national cyber security centre took its own website offline as a precaution, as did the Dutch House of Representatives. Sansec told stores they did not need to.

Working out whether PHP was running at all came first for many. Commenters found it behind OPNsense, OpenMediaVault, Nextcloud and Coolify, and commenter spartacle named why that was hard:

For quite a bit of homelab stuff, it’s really bad but I don’t know what languages a bunch of stuff uses, containers obfuscated this away from me.

Then came the wait for packages. Debian Trixie landed quickly while Ubuntu, Red Hat and the official Docker images trailed, and commenter Takeoded noted the Ubuntu security team had published nothing thirteen minutes after disclosure. Maintainer Ondřej Surý drew the loudest thanks on r/PHP, and his Launchpad PPA buckled under load, sending operators to packages.sury.org, where the PPA is being merged anyway. One team gave up on Docker Hub and built images from the merged Dockerfile themselves, finishing in eight minutes.

Confirming the patch had taken proved its own trap. Commenter SirRobinBlibs collected the ones that cost people time:

Distro builds backport. Ubuntu 24.04’s fixed package is 8.3.6-0ubuntu0.24.04.13, which still reports 8.3.6. Check the full package version against your distro’s tracker, not php -v. The CLI isn’t the web server. FPM/Apache workers keep the old engine in memory until restarted.

Ubuntu’s advisory confirms those version strings. Both PHP advisories tell operators to restart every worker after updating.

How bad it proved is still contested. Both CVEs carry AC:H and AT:P, high attack complexity with additional attack requirements, and Sansec revised its expectation of mass exploitation:

The public exploits do not work against a default PHP installation.

Practitioners found the same. SirRobinBlibs warned against testing with GitHub proof-of-concepts because "most of the starred ones don’t work on vanilla PHP, and malicious PoC repos are a known thing," and JFrog documented fake ones spreading as pranks, including one that changed the victim’s wallpaper.

Commenters on r/PHP asked how many people handle this work. The Foundation answered in the same post, writing that security work on PHP "still depends on a small group of foundation-funded developers" and that "today there are too few of them."

The upgrade gap drew the thread’s highest-voted comment, which called the end-of-life policy brutal. PHP 8.1 and older get nothing from the project, though it published minimal backports for 7.4, 8.0 and 8.1, and Ubuntu issued fixes as far back as 14.04 under ESM. PHP 8.2 reaches end of life on December 31, 2026.

A third issue, CVE-2026-115560, remains unpatched. PHP advises setting session.upload_progress.enabled=0 until the next bugfix release, when it will publish the full advisory.