PHP Patches Two Critical RCE Flaws That Were Already Under Attack

The PHP project shipped emergency security releases on October 21 across multiple active branches, deploying PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to remediate two critical vulnerabilities that allow unauthenticated remote code execution, as detailed in InfoQ's report. Tracked as CVE-2026-109618 and CVE-2026-109619 and collectively nicknamed php2shell, both vulnerabilities carry a CVSS v4.0 score of 9.2. Amazon Threat Intelligence disclosed that it detected an exploitation attempt in its MadPot telemetry four days prior to the release of the official fixes, originating from an IP address tied to a commercial anonymization network.

This analysis breaks down the breakdown of the coordinated vulnerability disclosure timeline, the mechanics of the underlying memory-safety flaws, which server architectures face proven exposure, and the operational steps required to secure production systems. It is intended for systems administrators, infrastructure engineers, DevOps practitioners, and homelab operators maintaining PHP runtimes across Linux distributions, containerized clusters, and web servers.

What broke in PHP Two Critical RCE Flaws That Were Already

The disclosure process broke down across several stages before the official patches went live on October 21. According to the PHP Foundation, the CVE identifiers began circulating publicly two days before the scheduled release date. A security researcher mistakenly published a demonstration video containing a working proof of concept, and commercial vendor Chainguard unilaterally broke the disclosure embargo by publishing container images containing the fix. Chainguard cited its policy allowing shortened embargo windows when vulnerabilities face active exploitation, which allowed external observers to study the patches in binary form while general users lacked upstream source updates.

The premature leak created an emergency window for platform defenders and infrastructure operators. Cloudflare deployed protective web application firewall rules at 03:02 UTC on October 21, approximately nine hours ahead of the official code drops. Operators on social forums reported shutting down web services entirely while waiting for upstream distributions to package the patches, and both the Dutch National Cyber Security Centre and the Dutch House of Representatives temporarily pulled their public websites offline as a defensive measure.

Who is exposed by PHP Two Critical RCE Flaws That Were Already

Exposure levels depend directly on the Server Application Programming Interface used to host PHP applications rather than the mere presence of the engine. Security firm Sansec traced the flawed memory routines back to every unpatched PHP release starting with version 5.4. However, upstream advisories confirmed that full remote code execution over HTTP was validated against Apache mod_php under default input and memory limits. Under PHP-FPM, researchers validated exploitability for the session lifecycle flaw, but the advisory noted that no complete remote exploit has been demonstrated for the out-of-memory routine.

FrankenPHP is considered likely susceptible based on source code analysis alone. Many administrators were surprised to discover embedded PHP runtimes running inside secondary services across their environments, including appliances and management dashboards like OPNsense, OpenMediaVault, Nextcloud, and Coolify. Homelab operators pointed out that container images frequently obscured the presence of underlying PHP runtimes, complicating initial asset inventories while teams scrambled to verify their real-world exposure profile.

What to do now about PHP Two Critical RCE Flaws That Were Already

The PHP Foundation stated plainly that there are no complete configuration workarounds, confirming that applying package updates is the only safe remediation path. Upstream versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 contain the source repairs, but systems running older distributions rely on distributor backports. For instance, Ubuntu 24.04 provides the fix under package version 8.3.6-0ubuntu0.24.04.13, which still reports 8.3.6 when checked via standard CLI commands. Operators must verify installed versions against distribution package managers rather than running php -v.

Restarting worker processes is mandatory because running Apache and PHP-FPM daemons retain the old, vulnerable binaries resident in process memory until restarted. Upstream maintainers provided minimal backport patches for unsupported branches 7.4, 8.0, and 8.1, while Ubuntu issued Expanded Security Maintenance updates dating back to Ubuntu 14.04. Furthermore, because a separate vulnerability tracked as CVE-2026-115560 remains unpatched, upstream maintainers instruct operators to set session.upload_progress.enabled=0 in php.ini until the next maintenance release ships.

How the PHP Two Critical RCE Flaws That Were Already issue works

Both vulnerabilities stem from critical memory-safety failures embedded within the PHP request lifecycle. One flaw originates within internal out-of-memory error handling routines, while the other involves state information that continues to persist after the system memory backing it has been freed. When triggered by tailored HTTP requests, these lifecycle anomalies allow unauthenticated remote attackers to manipulate memory structures and achieve remote code execution on the underlying host system.

Despite the severe 9.2 severity rating, both CVEs carry Attack Complexity High and Attack Requirements Present designations under the CVSS v4.0 scoring system. Sansec revised initial fears of automated widespread abuse, noting that public exploit chains fail against default PHP installations. Security researchers additionally cautioned operators against running unverified GitHub exploit scripts, noting that many starred repositories contained non-functional code, weaponized payloads, or pranks documented by JFrog that altered victim desktop wallpapers.

What is still unknown about PHP Two Critical RCE Flaws That Were Already

Significant uncertainty remains regarding the extent of early exploitation and the stability of long-term maintenance resources. Amazon Threat Intelligence confirmed seeing active exploitation attempts starting October 17 from anonymized infrastructure, but the broader industry lacks visibility into whether attackers achieved successful compromise on targets prior to Cloudflare's firewall deployment. In addition, the technical details surrounding the third issue, CVE-2026-115560, remain withheld until full disclosure occurs during the subsequent bugfix cycle.

The long-term resilience of the PHP ecosystem also faces open questions concerning engineering headcount and lifecycle schedules. The PHP Foundation acknowledged that core security maintenance depends on a small group of foundation-funded developers and noted that their current numbers are insufficient for the maintenance burden. With PHP 8.2 scheduled to reach formal end-of-life on December 31, 2026, organizations operating legacy web architectures face shrinking support windows without formal upstream security backports.