PHP2Shell and the Age of AI-Discovered Zero-Days

PHP2Shell is not just another critical patch. It is the first internet-scale zero-day in a core web runtime that was found by AI, leaked before the fix, and probed by attackers within hours. That combination is the story, and it is the shape of what comes next.

Last Wednesday, governments in Finland, the Netherlands and France pulled public websites offline. Hosting providers took entire customer estates down rather than risk compromise. The NSA told organizations to patch immediately or disconnect. For those of us running security operations for hundreds of clients, October 21 was a long day. This post explains what happened, why PHP has been here before, and why I believe this event marks a structural shift in how vulnerabilities are found and weaponized.

What happened: PHP2Shell in brief

Two memory-safety flaws in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619, give an unauthenticated attacker remote code execution on servers running PHP 5.4 through 8.5. The PHP security team rated each 9.2 under CVSS v4.0. Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP took the unusual step of backporting fixes to the end-of-life 7.4, 8.0 and 8.1 branches (Krebs, TNW).

The blast radius is the runtime, not an application. PHP's maintainers say every installation that handles web requests is potentially exposed, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed (SecurityWeek). That means WordPress, Drupal, Joomla, Magento, Moodle and every custom line-of-business app sitting on top of it. PHP powers roughly 70% of websites and remains one of the most widely deployed web runtimes on the internet.

Sources: PHP2Shell research site, NCSC-NL php2shell repository, Sophos advisory and SecurityWeek.

Exploitation reporting is still uneven. watchTowr, Patchstack, Cloudflare and Amazon all reported attempts around or before the patch, while CISA and Huntress said on day one they had not yet seen it. Early activity reportedly focused on web shells and cryptominers, while multiple security vendors warned that ransomware operators and state-sponsored threat actors would likely follow if patch adoption lagged. Treat any internet-facing PHP host that was unpatched on October 21 as a candidate for compromise, not just for patching.

One detail deserves attention from every CISO. According to public reporting, the underlying out-of-memory condition behind one of the vulnerabilities had been identified during prior PHP security review efforts and received renewed attention during a 2024 audit. The issue remained unresolved because no working remote-code-execution path had been demonstrated at the time. AI closed that gap between a known bug and a working weapon.

Historical context: PHP has been here before

In my view, PHP2Shell is the most severe security event in PHP's history, though reasonable people may debate that ranking against incidents such as the 2021 PHP source-code compromise attempt. The pattern is consistent: a flaw deep in the runtime or its server integration, a messy disclosure, and attackers moving faster than patch cycles.

The 2012 and 2024 entries are the most instructive. In 2012 an early, accidental disclosure forced a rushed fix, just as last week's leak did. In 2024 researchers found a way around that same 12-year-old fix, and ransomware operators exploited it within days. Old PHP bugs do not die; they get re-found.

Zoom out and PHP2Shell joins a familiar lineage of foundational open-source crises: Heartbleed and Shellshock in 2014, Log4Shell in 2021. Each hit a component so embedded that most organizations could not say where it ran. Wiz has already compared PHP2Shell to Heartbleed as a turning point (KEYT/CNN). The difference this time is who, or what, found the flaw.

Why this is a trend, not an anomaly

My view: PHP2Shell is the first mainstream proof that frontier AI models from OpenAI, Anthropic, Google and others have changed the economics of vulnerability discovery. Expect more events like it, in more foundational software, at shorter intervals. Six reasons.

1. Finding bugs in hardened code is now cheap and fast. PHP's core has been fuzzed and audited for decades. Calif said it did not expect to find anything critical because others had already run extensive AI-assisted audits, yet it assembled a working variant in a few days using generally available models (Washington Post via Inquirer, TNW). Anthropic's Project Glasswing tells the same story at scale: partners reported at least 129,000 verified vulnerabilities between April and July 2026 (SIG).

2. Independent rediscovery is becoming the norm. Calif, OpenAI and Wiz each found these bugs separately, with Wiz using Google's Gemini 4 Argon alongside OpenAI's model (TNW). When three well-funded defenders converge on the same flaw within weeks, assume well-funded attackers can too. The Amazon sighting on October 17 is consistent with that.

3. "Not exploitable" is no longer a safe triage verdict. The PHP2Shell root cause was known since 2020 and parked because no one proved it could be weaponized. AI turned a theoretical bug into a shell. Every backlog of "low-risk" memory-safety bugs in every open-source project now deserves a second look.

4. The patch-to-exploit window is collapsing toward zero. Calif's CEO warned that anyone could feed the published patches to an AI model and produce an exploit script (Deseret News). Sansec predicted mass exploitation within 15 minutes of release. Monthly patch cycles were built for a world where that window was measured in weeks.

5. Embargoes are getting more fragile. Coordinating a fix across PHP, cloud providers, CDNs and security vendors takes time and many hands. This embargo ran two months and still leaked a day early. More AI-found bugs mean more embargoes, more parties and more chances to leak.

6. Remediation, not discovery, is now the bottleneck. Anthropic's Project Glasswing and similar initiatives suggest that AI-assisted vulnerability discovery is scaling rapidly across widely deployed open-source software, increasing the volume of findings maintainers must evaluate and remediate. Early reports from AI-assisted research programs suggest that remediation capacity is becoming a larger constraint than discovery capacity. Maintainers often struggle to triage, validate and patch findings at the rate they are now being generated.

The counterpoint, in fairness. Volume is rising faster than severity, and human validation remains essential before organizations commit resources to remediation. Even so, it only takes one bug in a component as universal as PHP to take governments offline.

The labs know this, which is why access to their most capable cyber models is gated through programs such as Anthropic's Project Glasswing, OpenAI's Patch the Planet, and Google's Big Sleep. That buys defenders a head start. It does not guarantee one.

What to do: this week, and this year

This week (practitioners)

• Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply the backported fixes for 7.4–8.1. PHP endorses no workaround other than the update.
• Find the PHP you forgot. Container base images, vendor appliances, plugins bundling their own runtime, dev and staging boxes, and Windows hosts running php-cgi. Version banners are often hidden, so scan by behavior, not just headers.
• Hunt, don't just patch. Any internet-facing host unpatched on October 21 should be checked for new web shells, unexpected child processes of the PHP worker, outbound connections and cryptominer CPU spikes.
• Use WAF rules as a bridge, not a fix. Cloudflare and others shipped signatures, but they buy time only.
• Isolate what you cannot patch. CERT-EU's advice is to pull it off the public internet until it is fixed (SOCRadar).

This year (leaders)

• Fund emergency patching as a standing capability. If your change process cannot ship a runtime update to production in hours, it is now a business risk. Pre-approve emergency change windows for internet-facing tiers.
• Demand a live software inventory. The first question on October 21 was "where do we run PHP?" Too many organizations could not answer within a day. SBOMs and continuous attack surface management are no longer optional.
• Re-baseline "low" findings. Ask your teams and suppliers how they triage bugs marked hard to exploit. AI has made that label unreliable.
• Use AI on defense, on purpose. The same models that found PHP2Shell can review your own code, prioritize your backlog and accelerate detection engineering. Programs from the major labs exist to subsidize exactly this for defenders.
• Rehearse a "take it offline" decision. Open LMS chose to take every customer site down until patched (Open LMS). That was a sound call. Know in advance who in your organization can make it, and what it costs.
• Invest upstream. Your business runs on open-source maintainers who are being flooded with AI-found bugs. Supporting the foundations behind critical runtimes is risk reduction, not charity.

For MSP and MSSP clients specifically: this is where shared scale pays off. A provider that sees telemetry across hundreds of environments can spot first exploitation, push signatures and roll patches far faster than any single IT team. Ask your provider how quickly they knew where PHP lived in your estate last week. The answer tells you how ready they are for the next one. All Covered's managed cybersecurity services help organizations improve threat visibility through proactive security monitoring, vulnerability management, and remediation guidance.

Closing thoughts

The bugs in PHP2Shell sat in plain sight for years. What changed was not the code but the cost of understanding it. AI has made deep vulnerability research fast, cheap and repeatable, and that capability does not stay on one side of the fight. This does highlight a very disturbing pattern in our defensive methods. We must be way more aggressive in combining vulnerability discovery and remediation teams to secure an almost immediate outcome. if we haven't done so already, that something to put on the roadmap.

The bugs in PHP2Shell sat in plain sight for years. What changed was not the code but the cost of understanding it. AI has made deep vulnerability research fast, cheap, and repeatable, and that capability does not stay on one side of the fight. Defenders got there first this time, with two months to prepare. The warning is that the head start shrank to days through a leak, and attackers were already probing before the patches were released. The organizations that came through last week well had three things in common: they knew where their software ran, they could patch in hours, and they were willing to take systems offline when needed. Build those three capabilities now. The next PHP2Shell is already being found.