PHP2Shell: A Hole in 70% of the Web

The crown jewel of Black October is PHP2Shell, a vulnerability that exposes the language running behind roughly 70% of websites whose server-side tech is known. Two critical flaws, CVE-2026-109618 and CVE-2026-109619, rank at CVSS 9.2, and they’re embedded deep in PHP’s core engine, not in any application layer.

These aren’t your garden-variety web app bugs. According to Wiz Research’s technical breakdown, the vulnerabilities enable unauthenticated remote code execution and memory disclosure that can expose passwords, tokens, API keys, and certificates. The researchers demonstrated full pre-authentication RCE against WordPress, Drupal, and Joomla, but the exploitation doesn’t depend on those platforms at all. Even a simple “Hello World” app running on a vulnerable PHP version is exposed.

The response was dramatic: the NSA explicitly warned website operators to take sites offline if they couldn’t patch immediately. The UK took 32 government services down. Dozens of sites worldwide followed suit.

The AI Inflection Point

Here’s what makes PHP2Shell different from every vulnerability that came before it: AI discovered it.

The bugs had been lurking in PHP since version 5.4, over a decade of accumulated technical debt in memory management and error handling. Exploiting them required chaining multiple complex vulnerabilities together, adapting to memory layouts across different PHP versions and configurations. Pre-AI, this was the kind of work that took world-class teams months.

Wiz Research, using Gemini 4 Argon and GPT-5.6 Sol, turned that timeline into a week. One researcher, with frontier models and the right tooling, replicated what would previously have required an entire specialized team.

OpenAI called the discovery “one of the most impactful security issues in recent memory”, noting that “frontier AI found these vulnerabilities before attackers did.”

That last part matters, because it’s the only reason this is a story about patching rather than a story about mass compromise.

The Exploitation Timeline Is Shrinking

But here’s the uncomfortable truth from Amazon Threat Intelligence’s analysis: someone out there had exploit code four days before public disclosure. On October 17, Amazon’s MadPot honeypot network detected exploitation attempts from an IP address associated with a commercial anonymization network. During the embargo period.

The window between patch release and weaponized exploit is collapsing. AWS observed multiple proof-of-concept exploits within hours of the embargo lifting at 14:00 UTC on October 21, with “additional exploitation attempts… from additional anonymized infrastructure” using different payloads and infrastructure choices, suggesting multiple independent actors were ready to move.

The takeaway from CJ Moses, Amazon’s CISO, cuts to the bone: coordinated disclosure is still the right model, but defenders should never assume the disclosure date is the earliest exploitation date. For PHP2Shell, compromise may predate the advisory by days.

This Was Never Just About PHP

The PHP browser tab was still open when the rest of the internet started collapsing. The compiled list of incidents circulating through security circles reads like an apocalypse checklist:

And that’s not even the complete list. Medi-Cal lost 970,000 patients’ data. The State Bank of India confirmed a breach. Tor had 333 relays hijacked. OVHcloud shipped a password stealer in an official tool. The Ahold Delhaize grocery chain, owner of Food Lion and Stop & Shop, got knocked offline entirely.

The Private Key Was the Number 4

Perhaps the most absurd entry in this cascade of failures is eMudhra, an Indian certificate authority that handled the cryptographic trust infrastructure for global SSL/TLS certificates. Mozilla discovered that eight of eMudhra’s certificate private keys had been compromised. These keys should be 116-digit numbers. One of them was just 4.

Not a number starting with 4. Not 4 followed by 116 random digits. The literal number 4. Anyone on the internet could guess it and forge HTTPS certificates for any website.

The company’s response? It announced it was exiting the global SSL/TLS certificate business entirely, revoking the compromised certificate authorities within 14 hours. Chairman V. Srinivasan cited rising compliance costs, competition from free providers, and “outsized social media scrutiny” as additional factors.

The more cynical read, echoed across security circles, is that eMudhra’s catastrophic cryptographic failures in certificate authority infrastructure were the real problem, and blaming Twitter was a convenient way to deflect from the fact that their private keys were single digits. The company claimed it issued no end-entity certificates from the compromised CAs and confirmed no infrastructure breach or data loss. That’s cold comfort when the keys themselves are mathematically trivial to guess.

When the Defenders Are Outgunned

The pattern across Black October points to a structural shift in cyberwarfare. As one security professional observed, “AI hacking can only be countered by AI cybersecurity. It will from now on become a battle of who has the best models and the most access to compute.”

But there’s a catch. The models available to defenders fighting these attackers have restrictions. AI industry insiders sounding alarms about systemic risks and automation threats have noted that guardrails kick in quickly when defense teams ask cybersecurity questions. Meanwhile, threat actors have access to unrestricted models with no such limitations. Defenders are playing with a stacked deck.

One analyst put it bluntly during a patch deployment cycle: the average patch used to address between 50 and 70 CVEs. This week alone, the number was over 1,000.

What Black October Actually Means

The most disturbing realization about Black October isn’t the volume of incidents, it’s that many of these vulnerabilities stem from decades of accumulated technical debt. PHP’s flaws date back to architectural decisions made in the mid-2010s. GitLab’s hole predates 2014. Organizations have run unsupported PHP 6 or older versions for years simply because “updates can wait.”

One IT security team discovered servers running PHP 6 or older during the emergency response. Not because they didn’t know, because they’d deferred patching indefinitely. The “giant bank of fate” came calling, and it demanded payment in downtime.

As one researcher noted: “Zero days aren’t tech debt, though. New zero days will keep dropping as models get better. Even a shop that seems completely up to date still has to keep sprinting to keep up.”

This is the new normal. The time from patch to working exploit is shrinking for structural reasons: AI-assisted analysis makes it cheaper to turn a patch diff into a working exploit. More actors can act within hours or even minutes of a vulnerability being disclosed. The dependency on elite exploit developers is weakening.

Your Move, Defender

For security leaders, the operational implications are stark:

1. Measure patch timelines in hours, not days. A 7-day or 30-day SLA assumes a delay that no longer exists. For internet-facing systems, the clock starts ticking at disclosure, or before.
2. Start investigations from earliest known exploitation, not disclosure date. For PHP2Shell, that means investigating from October 17th at minimum.
3. Invest in detections that don’t rely on CVE-specific signatures. The first exploitation will often arrive before signatures exist.

The open-weight AI models challenging proprietary systems amid growing security concerns have an important role to play here. So does Cloudflare’s Clef, which enables transparent, auditable AI decisions in critical infrastructure. The defenses we build need to be as adaptable as the attacks coming at them.

The Bottom Line

We’ve entered an era where vulnerability discovery and exploitation are becoming democratized by AI. The open-sourcing of AI inference frameworks during a period of heightened cyber risk is a double-edged sword, the same capabilities that let researchers find and patch PHP2Shell in a week are available to anyone with the will to use them maliciously.

The question isn’t whether another Black October will happen. It’s whether we’ll use this one to fundamentally change how we build and secure the internet, or whether we’ll patch the most critical holes, declare victory, and wait for the next cascade.

The security researchers I’ve spoken to aren’t optimistic about the latter. And after the last 48 hours, neither am I.

What’s your organization doing differently in response to Black October? Are you treating it as a wake-up call or a one-off event? The answer will determine whether you’re prepared for what comes next.