PHP2Shell: AI Found the Path; Who Verifies the Fix?

A team can update every WordPress plugin and still leave a vulnerable PHP worker serving requests. That is the uncomfortable lesson of PHP2Shell: the flaw sits below the application, while the people responsible for the application may not control the runtime beneath it.

The name covers two PHP core vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. Researchers demonstrated unauthenticated remote code execution on representative applications and, separately, disclosure of sensitive PHP process memory. The affected code is in PHP itself; WordPress, Drupal, and Joomla were demonstration targets, not the only applications at risk. Whether a particular service is exposed depends on its running PHP version and configuration. PHP security advisory · Wiz research

This analysis reflects public information available on October 22, 2026. It does not claim to reproduce the exploits or establish that any particular website was compromised.

Timeline based on the PHP Foundation’s incident account, Wiz’s research timeline, and the PHP release advisory. The September–October phase represents ongoing coordination, not a single start date.

An old weakness became an actionable exploit

The story did not begin with a model discovering an entirely unknown line of code. During a 2024 security audit, PHP developers saw early signs of the out-of-memory problem behind one of the CVEs. A possible exploit was discussed, but no concrete remote path had been established. Proposed fixes carried compatibility, availability, and extension-ecosystem costs; work stalled. The PHP Foundation describes this delay as a failure of both decision-making and resourcing. PHP Foundation’s account

In August 2026, Calif, OpenAI, and Wiz submitted findings that made the impact harder to set aside. OpenAI says Calif used GPT-5.6 Sol in its research; Wiz says it used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol across discovery, exploit development, and patch validation. Those are the participants’ descriptions of how they worked, not evidence that a model independently made the security decision or wrote a production-ready fix. PHP maintainers led the repair and release. PHP Foundation’s account · OpenAI’s coordination account · Wiz research

Wiz’s published timeline gives this claim a concrete shape. Its team says it found the first vulnerability on August 19, confirmed unauthenticated code execution against Drupal on August 20 and WordPress on August 21, and reported its findings to PHP on August 24. The team also demonstrated an application-independent route to disclosing PHP worker memory. In its research, that disclosure helped reduce uncertainty about memory layout when developing other exploit chains. These were demonstrations in selected environments, not a measurement of how many websites could be compromised in practice. Wiz research and disclosure timeline

AI’s practical contribution was to shorten the distance between a suspicious failure and a working demonstration. Memory behavior changes with PHP versions, request sequences, and deployments. Wiz describes models working with testing and debugging tools to analyze failed attempts and adjust across those differences. It specifically credits Gemini 4 Argon with contributing to discovery, exploit development, attack detection, and patch validation. Wiz says its researchers adapted working demonstrations across several applications in hours; that is the team’s account of this investigation, not a general benchmark for automated exploitation. The same capability gives defenders a chance to investigate neglected bugs sooner, while potentially lowering the effort needed to adapt an exploit after disclosure. Neither claim establishes that every affected server has been attacked. Wiz research

Disclosure sped up before distribution was ready

On October 20, the CVE identifiers circulated ahead of the planned release. The PHP team brought forward its advance notice and moved the security release from October 22 to October 21 at 14:00 UTC. According to the PHP Foundation, technical details had not been included in the initial leak; a mistakenly published demonstration and an early release of patched images added pressure later. Distributors still needed time to prepare packages that operators could actually install. October 20 was therefore an early warning, not the date on which the complete advisory and fixed releases became available. PHP Foundation’s disclosure timeline

That timing reveals a bottleneck AI cannot solve alone. Finding a bug is one step. Maintainers must fix the root cause without breaking existing software; distributors and hosting providers must package it; operators must deploy it to every relevant runtime. An alert reaches people much faster than a tested patch reaches a live worker. PHP Foundation’s account · OpenAI’s coordination proposal

What a completed repair looks like

PHP lists 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as the fixed releases for supported branches. PHP 8.1 and earlier no longer receive regular upstream releases; a distributor or long-term-support vendor may supply a backported fix, but that has to be confirmed for the actual package in use. Otherwise, the service needs a supported runtime. PHP security advisory

The most useful question is not “Did we update the site?” but “Which PHP process handles the public request now, and what proves it is patched?” A container tag, a developer’s command-line php -v, and a CMS update are not necessarily evidence about the web-facing worker. In managed hosting, the provider may control that worker; in a custom image, rebuilding and redeploying it may be the customer’s job. Ownership has to be resolved before anyone can honestly mark the incident closed. Google Cloud’s runtime-specific guidance · PHP security advisory

A WAF and runtime monitoring can reduce exposure or help identify suspicious behavior while updates roll out. Neither proves the PHP engine is fixed. Even a rule that blocks an exploit-related HTTP response cannot undo an action already performed at the origin. Likewise, 2FA and phishing defenses address different risks; changing application code or plugins does not repair a flaw in PHP core. Cloudflare’s WAF analysis · PHP security advisory

The enduring lesson

PHP2Shell is less a contest between AI models than a test of the whole response chain. AI-assisted researchers helped turn a long-standing concern into evidence of real impact. Human maintainers made the difficult fix. Providers and operators still have to establish where PHP runs, who owns each update, and whether the patched process is actually serving traffic.