PHP fixes two critical RCE flaws that were already under attack

What was fixed

On October 21, the PHP project released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to close two vulnerabilities nicknamed "php2shell": CVE-2026-109618 and CVE-2026-109619, both rated 9.2 in CVSS v4.0. According to a report by InfoQ, both are memory-safety flaws in the request lifecycle: one in out-of-memory handling, the other in state that outlives the memory meant to contain it.

Security firm Sansec says the flaws exist in every unpatched PHP version since the 5.4 series. The official advisory is blunt about the available options:

There are no complete mitigations; updating is the only safe choice.

PHP project security advisory

The race against the exploit

The patch didn't arrive before the attack. Amazon Threat Intelligence identified an exploitation attempt on October 17, four days before the fix existed, originating from an IP address associated with a commercial anonymization network, according to InfoQ. The company advised customers to investigate logs starting from that date.

Cloudflare reacted even before the official release: it deployed WAF rules at 03:02 UTC on October 21, about nine hours before the patch became available. This shows that infrastructure providers already had enough information to act while part of the community didn't even know about the problem yet.

Who is exposed: mod_php, FPM, and FrankenPHP

Actual exposure depends on how PHP is served, and the advisories are cautious about what has actually been proven. For Apache with mod_php, remote code execution was validated for both flaws, tested over HTTP against an installation with default input and memory limits.

On PHP-FPM, only the case tied to session lifecycle was validated as a full exploit; for the out-of-memory flaw, the advisory states that "no complete exploit for this SAPI has been demonstrated" so far. FrankenPHP is flagged as likely vulnerable, but only based on source-code analysis, with no exploit demonstrated publicly.

The collapse of coordinated disclosure

The responsible disclosure process didn't hold up to the end. According to the PHP Foundation's own account, cited by InfoQ, the CVE identifiers began circulating two days ahead of schedule, a researcher "mistakenly published a video" showing a proof of concept, and Chainguard "unilaterally broke the embargo and published images already carrying the fix."

The consequence, according to the Foundation, was that any attacker could study the fix in binary form while the rest of the PHP user base was still waiting for the official release. Chainguard's public policy, updated one month before the incident, allows the company to shorten disclosure timelines when a vulnerability is identified as already under active exploitation, which the company used to justify the decision.

Community reacts: sites go offline

Some operators chose to shut down services rather than wait for the patch. On r/selfhosted, user iamShorteh described the decision:

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.

iamShorteh, comment on r/selfhosted

The Netherlands' national cybersecurity center took its own site offline as a precaution, as did the Dutch House of Representatives. Sansec, on the other hand, told stores using its platform that the measure wasn't necessary for them.

Checklist: what to do now

Anyone running PHP in production faces two problems in sequence: first figuring out where PHP is running, then confirming the patch actually took effect. On r/selfhosted, users reported finding PHP hidden behind OPNsense, OpenMediaVault, Nextcloud, and Coolify without realizing it at first.

A comment from user spartacle sums up the problem:

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.

spartacle, comment on r/selfhosted

Confirming the update also has pitfalls, listed by user SirRobinBlibs on r/PHP:

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 with php -v. The CLI isn't the web server. FPM/Apache workers keep the old engine in memory until restarted.

SirRobinBlibs, comment on r/PHP

In practice, that gives a minimal checklist:

• Don't trust php -v: compare the full package version against your distro's official changelog.
• After updating, restart all PHP-FPM and Apache workers, both advisories explicitly require this.
• Don't test with proof-of-concept code from GitHub: JFrog documented fake repositories circulating, including one that just swapped the victim's wallpaper as a prank.
• While your distro's package hasn't arrived yet: Debian Trixie had the patch available quickly, but Ubuntu, Red Hat, and the official Docker images took longer.

The delay created a bottleneck: maintainer Ondřej Surý's PPA, one of the most widely used for PHP on Ubuntu, buckled under the extra demand, leading operators to migrate to packages.sury.org, where the PPA is being incorporated.

The dispute over actual severity

Not everyone agrees on the size of the practical risk. Both CVEs carry AC:H (high attack complexity) and AT:P (attack requirements present) attributes in CVSS, which limits who can actually exploit them. Sansec itself revised its initial expectation:

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

Sansec

That doesn't mean the risk is low, only that it depends on specific configuration. For anyone managing PHP infrastructure in production, the practical recommendation doesn't change: updating remains the only safe path, since there's no complete mitigation outside the patch.

The underlying problem: too few hands guarding PHP's security

Users on r/PHP asked how many people actually look after the language's security. The PHP Foundation itself answered in the same disclosure post about the incident, admitting that security work "still relies on a small group of developers funded by the foundation" and that "today there are too few of them."

This exposes a structural issue that goes beyond this specific incident: PHP runs a huge slice of the web, but the capacity to respond to critical vulnerabilities is limited. For whoever decides the stack at companies that still rely on legacy PHP, this is a factor to weigh alongside the roadmap of supported versions.

On this front, the end-of-life policy also matters. PHP 8.1 and earlier versions no longer receive anything from the official project, although minimal backports were published for 7.4, 8.0, and 8.1; Ubuntu, for its part, issued fixes even for version 14.04 under its Extended Security Maintenance (ESM) program. PHP 8.2 reaches end of life on December 31, 2026, which leaves little time for anyone still on that version to plan a migration.

The third problem, still unpatched

A third flaw, CVE-2026-115560, remains without a published fix. In the meantime, the PHP project recommends setting session.upload_progress.enabled=0 as a temporary mitigation, until the next bugfix release ships with the full advisory.

For anyone administering PHP environments in production, the case reinforces a routine worth keeping even after the dust settles: monitor the project's official security channels, automate full package version checks (not just php -v), and make sure the deploy process always includes a worker restart after a security patch.