PHP2Shell: Critical RCE Flaws in PHP Exploited Before Patch Release, Amazon Confirms

Attackers were already probing PHP servers for two critical remote-code-execution vulnerabilities four days before the PHP development team publicly disclosed the flaws on October 21, 2026. Amazon Threat Intelligence confirmed the pre-patch exploitation using its MadPot honeypot network, which logged the first attempt on October 17. The vulnerabilities — CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 on the CVSS severity scale and collectively called PHP2Shell — affect every major PHP web server deployment mode. The U.S. Cybersecurity and Infrastructure Security Agency, the FBI Cyber Division, and the UK National Cyber Security Centre all issued simultaneous advisories urging immediate patching. With proof-of-concept exploits circulating within hours of the patch release and Amazon confirming "PHP2Shell is now being broadly exploited in the wild," organizations face an extraordinarily narrow remediation window.

Two Memory Corruption Paths to Unauthenticated Remote Code Execution

Both CVEs exploit low-level memory management behavior in PHP's C runtime but represent distinct failure modes.

CVE-2026-109618 exploits how PHP handles a request that exceeds the configured memory_limit. When PHP exhausts allowed memory, it calls longjmp() — a C standard library function that exits the current execution context without unwinding the call stack. Destructors do not run; partially initialized data structures remain in memory in an inconsistent state. PHP's request-shutdown sequence then treats that corrupted state as valid, creating conditions for use-after-free or access of uninitialized memory. An attacker who deliberately triggers an out-of-memory condition at a precise execution point can manipulate the resulting memory layout to achieve unauthenticated remote code execution as the web server worker account. Researchers classify this under CWE-416 (Use After Free), CWE-755 (Improper Handling of Exceptional Conditions), and CWE-824 (Access of Uninitialized Pointer). Wiz Research provides a full technical breakdown of both CVEs, including demonstrated pre-authentication RCE against WordPress, Drupal, and Joomla.

CVE-2026-109619 targets a separate weakness: PHP retains request-specific global variables between requests in long-running worker processes. PHP-FPM, mod_php, FrankenPHP, and LiteSpeed maintain worker pools for performance efficiency, reusing a single process across thousands of sequential requests. A timing window exists in which a new request begins executing before the prior request's backing memory is fully freed and reinitialized. A request that lands during this window dereferences stale pointers, enabling heap use-after-free, memory disclosure, and unauthenticated RCE. This design condition — worker-process reuse without strict memory isolation between requests — traces to PHP's origins as a single-request CGI interpreter and has persisted through more than two decades of architectural change.

AI Security Tools Found What Manual Auditors Missed for 14 Years

The PHP Foundation says exploitation scenarios were theorized as early as 2024, but no concrete attack vector was identified, and fix work stalled repeatedly as key experts were "occupied with many responsibilities."

Concrete exploitation paths were ultimately identified through AI-assisted code analysis. According to the PHP Foundation, security firm Calif, working under OpenAI's Patch the Planet initiative — a coordinated program connecting security researchers, maintainers, and incident responders to address critical open-source vulnerabilities — used GPT-5.6 Sol to identify CVE-2026-109618. Independently, Wiz Research used its Wiz Atlas security AI agent in combination with Gemini 4 Argon and GPT-5.6 Sol to discover both CVEs. Wiz reports the discovery — from first finding to confirmed RCE against production CMS platforms — took a single researcher approximately one week, work the team said would previously have required a world-class team and months of effort. Both independent discoveries had reached the PHP Foundation by late August 2026, with PHP formally acknowledging the reports and beginning coordinated remediation in September.

OpenAI framed the outcome as a capability threshold: "It also marks a new phase, where AI can find security bugs with internet-scale impact." The simultaneous independent discovery by two teams using different AI tool stacks supports that framing — the result appears reproducible rather than coincidental.

Exploitation Began Before the Announcement — and Forced It Early

Amazon's October 17 detection is the most operationally significant finding: an unknown threat actor targeted a MadPot decoy system four days before the planned disclosure, using what appears to have been knowledge of PHP2Shell before the vulnerabilities were publicly described.

When the vulnerabilities began circulating on online forums and social media, the PHP team accelerated its release. Cybersecurity firm watchTowr stated on October 20 — the day before the official patch — that the flaws "could let attackers run their own code on affected servers," indicating the embargo had broken.

Within hours of the October 21 patch release, proof-of-concept exploits appeared and Amazon's sensors recorded them being used against honeypots almost immediately. The variation in exploit techniques across attack attempts led Amazon to conclude multiple independent threat actors had acquired knowledge of the flaws. Amazon noted it cannot determine whether any attempts would have succeeded against hardened production infrastructure — an important caveat in the absence of confirmed real-world compromises.

Every PHP Deployment Mode Carries the Risk — and Patches Are Available

PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed LSAPI are all affected. The vulnerability class is not limited to a single execution model; any PHP server mode involving worker-process reuse or request-boundary memory management is in scope.

Patches are available for four maintained release series: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, all released October 21, 2026. PHP 8.1 and earlier have reached end-of-life and will not receive patches; upgrading to a supported series is required.

The PHP team describes patching as the only complete remediation. Temporary measures — lowering memory_limit, restricting upload_max_filesize and post_max_size — narrow the attack surface for CVE-2026-109618 but do not address CVE-2026-109619 and leave internet-facing servers at risk. The FBI's advisory was explicit: if immediate patching is not feasible, take the system offline.

A 14-Year Bug and a Coordinated Disclosure That Broke Down

The PHP Foundation's post-incident statement is unusually candid. After years of stalled fix work, AI-assisted vulnerability research produced concrete exploitation paths by late August 2026 — but the disclosure timeline then had insufficient runway before information leaked. The Foundation acknowledged: "We won't pretend otherwise: the delay was a structural failure."

That admission describes a problem broader than a single vulnerability. A flaw theorized in 2024, concretely vectored by August 2026, and already being actively exploited by October 17 represents a window of at least several weeks between when exploitation was plausible and when defenders had actionable patches. Organizations should treat October 17 as the start of the potential compromise window and review server logs, process execution records, and web application firewall events going back to that date.

AI-Accelerated Discovery Is Outpacing the Defender Ecosystem

PHP2Shell's secondary significance is what it reveals about the current state of AI security research. For decades, critical memory-safety vulnerabilities in widely deployed C-based runtimes were found through manual review, fuzzing, or post-exploitation. PHP2Shell was found by AI-assisted auditing before active attackers had independently vectorized the path — but only by a narrow margin, and the coordinated-disclosure infrastructure failed to hold the line.

The convergence of two separate AI platforms on the same previously unvectorized vulnerability class suggests AI code analysis has crossed a practical threshold for C runtime memory-safety bugs. The more pressing structural question now is whether responsible disclosure processes can absorb AI-accelerated discovery rates. When AI tools identify vulnerabilities months faster than traditional audits, the window between discovery and defender readiness compresses dangerously. PHP Foundation's forthcoming post-mortem and any process changes it produces will be the early evidence for whether the security community has a credible answer.