PHP2Shell: AI Found the Bug. AI Has to Fix It Too.

Two unauthenticated remote code execution vulnerabilities in the PHP core runtime, rated CVSS 9.2, were disclosed on October 21, 2026 after sitting in the codebase since PHP 5.4. Wiz Research found them using Gemini 4 Argon and GPT-5.6 Sol. They affect every PHP version released in the past 14 years. The patching race started before the public knew there was anything to patch.

What the Bugs Actually Are#

Both CVEs trace to the same underlying pattern: PHP mishandles fatal out-of-memory errors mid-request, leaving corrupted internal state that a subsequent worker request can reuse. CVE-2026-109618 involves an upload-progress unserializer use-after-free that enables unauthenticated memory disclosure and code execution. CVE-2026-109619 involves a fatal-error backtrace use-after-free and an OPcache type confusion, both of which Wiz demonstrated as pre-authentication RCE chains against WordPress and Drupal.

The vulnerabilities live in PHP's engine, not in any application. A "Hello World" PHP app running on an affected version is as exposed as WordPress.

The Timeline Is the Story#

According to the PHP Foundation, signs of CVE-2026-109618 appeared during PHP's first external security audit in several years , back in 2024. Engineers debated it. Concerns about backward compatibility, denial-of-service potential, and the coordination burden of changing third-party extensions caused work on a fix to stall and restart repeatedly over months. No patch shipped.

Then, in August 2026, AI code review tools from Anthropic and OpenAI scanned PHP. A researcher at cybersecurity firm Calif reported the bugs on August 11. Wiz Research independently confirmed unauthenticated RCE against Drupal on August 20 and against WordPress on August 21. The PHP Foundation made fixing the issue its top priority from that point forward.

The coordinated disclosure was supposed to run clean. It did not. Details leaked on social media on October 20. A video from Calif showing proof-of-concept exploitation was deleted but circulated anyway. Amazon Threat Intelligence later reported that exploitation attempts had begun on October 17, four days before any patch existed. Palo Alto Networks identified more than 22.6 million exposed instances. Cisco Talos estimated roughly 50% of vulnerable PHP systems may never receive a patch, because the PHP project is not backporting fixes beyond PHP 8.2.

The AI Paradox Nobody Is Talking About Directly#

The debate about AI-generated code , slop, vibe-coding, unreviewed output from assistants , frames AI as a source of new risk. PHP2Shell is a direct counter-example. The vulnerabilities are human-written, battle-hardened, in production since 2012. What AI changed was not who wrote the code but who could find and exploit the flaw. Wiz notes that building a working exploit previously "would have taken a world-class team months of work." With Gemini 4 Argon, a single researcher completed comparable work in a week.

This cuts in both directions. The same capability that reduces the time to build an exploit reduces the time to find the vulnerability defensively. Raluca Ada Popa, Head of Gemini Security at Google DeepMind, said in the Wiz disclosure that frontier models helped "bridge that gap, finding vulnerabilities and helping patch them." Both sentences of that quote matter equally.

Why This Changes the Scope of Code Review#

The standard framing of automated code review, particularly since AI coding assistants became common, is that the tool audits new code before it merges. PHP2Shell makes that framing incomplete. The 14-year-old memory-handling code in PHP's core engine was not "new code." It passed every review it ever received. The threat model has shifted: AI-assisted security research is now capable of surfacing complexity that human reviewers did not previously reach at scale.

That means any serious review program has to cover the full codebase, not just recent commits. The attack surface includes the framework beneath the application, not only the application logic. Hyrax's security domain scans across the entire repository on every audit run , new code and old alike , because the distinction between "freshly written" and "thoroughly reviewed" has never been a reliable proxy for "safe."

The failure mode in PHP's case was not ignorance of the bug's existence. The 2024 audit surfaced it. The failure was in the decision loop: a known issue, contested tradeoffs, no path to consensus, no fix. That is an organizational and process problem as much as a technical one.

What Comes Next Is Uncertain#

PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 are patched. PHP 8.1 and earlier receive no fix. VirusTotal analysis cited in The Record put 758,000 IP addresses on end-of-life PHP versions at time of disclosure. Those servers will not be patched through any official channel. Cloudflare, AWS, Google Cloud, and others deployed WAF mitigations, but WAF rules are perimeter controls, not remediations. They buy time. Whether that time is used effectively depends on how quickly operators can update runtime dependencies they may not have known were in scope.

The deeper question PHP2Shell raises is whether the industry's coordinated disclosure process, designed for a world where exploit development took months, can function in one where it takes a week. Chainguard CEO Dan Lorenc, defending the company's decision to break the embargo early after seeing exploitation attempts, said: "We, as an industry, have to figure out how to get through them faster and more coordinated and better." That is probably right, and the answer is not yet obvious.

Hyrax is live at hyrax.dev.