PHP 兩個漏洞潛伏逾十年，AI 輔助研究人員數周內構造出可行漏洞利用

On Wednesday, Finland took its government websites offline. The Dutch parliament went dark. Edinburgh council's site disappeared. Parts of Wikipedia stopped loading. Even a few BBC programme pages went down.

The reason: two bugs in PHP, the language that quietly runs most of the web. The vulnerable code had been sitting there for more than a decade. Then AI-assisted researchers turned it into working exploits within weeks, and everything kicked off.

This is the story of PHP2Shell, and I think it's the most interesting security story of the year, because the good guys and the bad guys are about to use the exact same trick.

First, what actually broke

PHP powers roughly 70% of websites, according to Wiz's estimate. WordPress, Drupal, Joomla, MediaWiki (the software behind Wikipedia) and a mountain of shared hosting and control panels all sit on top of it. If you run WordPress or WooCommerce, which is the stack I build on, your server runs PHP.

On October 21, the PHP team patched two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. Researchers named them PHP2Shell, which tells you the punchline: unauthenticated remote code execution. An attacker doesn't need a login, and they don't need a bug in your code. The bugs are in PHP itself, so even a "Hello World" app on a vulnerable version can be exposed.

The technical idea is elegant in a nasty way. When PHP hits a fatal error, like running out of memory mid-request, it can leave corrupted internal state behind. The worker process survives, and the next request handled by that same worker can inherit the stale state. Chain it right and you get use-after-free primitives that turn into full code execution, demonstrated on default WordPress, Drupal and Joomla installs.

One of the bugs is worse in a quieter way. It lets an attacker read the PHP worker's memory remotely, including passwords, tokens and API keys from other people's requests, and the stolen data comes back inside a PHPSESSID cookie. Wiz compared it to Heartbleed, and the comparison is fair. No login, no code execution needed. Ask nicely and the server hands you its secrets.

Image: Wiz Research

The part that reads like fiction

The vulnerable code survived more than a decade of humans reading it. There's a reason for that, and it isn't that nobody cared. According to Tom's Hardware, the PHP Foundation had known something was wrong with the underlying code since 2024, but couldn't identify an exploitation method or a fix. The chain was too complex to demonstrate: too many steps, too much fiddly memory layout work.

Then two teams, working independently, pointed frontier AI models at it.

Calif, a security testing firm in OpenAI's "Patch the Planet" program, began auditing PHP with GPT-5.6 Sol on July 30, at the PHP Foundation's request. Researcher Ryan A. identified the exploitable vulnerability on August 11, with OpenAI researchers finding it the same day, per Tom's Hardware's reporting of OpenAI's account.
Wiz found related bugs separately using its Atlas agent, Google's Gemini 4 Argon and GPT-5.6 Sol. Its own timeline: first discovery August 19, working RCE against Drupal the next day, WordPress the day after, everything reported to PHP by August 24.

Wiz's claim stuck with me: "a single researcher completed in a week what previously would have taken a world-class team months of work." The bugs weren't new. What changed is that exploiting them stopped being impractical.

Then it leaked, and attackers moved fast

The plan was a calm, coordinated disclosure. Patches and technical details were scheduled for October 22, with defenders briefed in advance. That's not what happened.

On October 20, details of the flaws leaked on social media, and the release was pulled forward a day. Separately, and more worrying: Amazon said it identified hackers attempting to exploit the bug four days before public disclosure, and described the flaws as "now being broadly exploited in the wild."

Two honesty notes here. First, those are exploitation attempts reported by Amazon via the Financial Times and Ars Technica; CISA said it had not observed exploitation as of its October 21 advisory, and I've seen no confirmed breach attributed to these bugs yet. Attempts are not the same as a successful compromise. Second, the "AI found it first" claim needs care. It's OpenAI's account, and it covers discovery: the private window was real, about two months from the August discoveries to the October patch. But the public window was essentially zero. Amazon says exploitation attempts were already happening four days before disclosure, so by the time the world knew, attackers were already moving.

Either way, Wednesday looked dramatic. The NSA, CISA and FBI warned organizations to patch immediately or take systems offline, with the NSA saying the vulnerabilities "often provide a direct path to the server's file system or database." The UK's NCSC, CERT-EU, and agencies in Australia and Japan issued similar advice. Japan's Prime Minister personally posted on X urging people to check whether their sites run PHP, per the BBC. When a head of government is doing patch comms, it's a real one.

The honest bit: AI did not simply save the day

It would be easy to read this as an AI triumph story. It isn't, quite.

On OpenAI's account, defenders got there first on discovery. OpenAI calls that lead time a "Defender's Window" and used it to coordinate a genuinely impressive response: WAF rules ready at Cloudflare, AWS, Akamai and Fastly before public disclosure, government agencies engaged, and $1 billion committed in subsidized security tooling for under-resourced defenders.

But Wiz is blunt about the flip side: "With AI this is no longer a barrier. LLMs can help adapt an exploit to different PHP versions, configurations and memory layouts." The same capability that let Calif and Wiz build these exploits is the capability that makes the bugs dangerous now. For a decade, these flaws were protected by the sheer difficulty of exploiting them. That protection just expired, for defenders and attackers alike.

Also, one caveat on scale: the "70%" figure is Wiz's estimate of PHP's share of websites, and the BBC noted it couldn't verify it. Usage share also isn't the same as exploitable share, and nobody has published a solid count of how many servers are still unpatched. Even so, the vulnerable footprint is enormous by any measure.

What I'd actually do (the boring checklist)

If you run anything PHP, and if you self-host WordPress or WooCommerce that's you:

Patch the runtime, not the app. Updating WordPress does nothing here. Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart Apache, PHP-FPM and any long-running PHP workers, per the official guidance.
If you can't patch, take it offline. That's not me being dramatic: CISA says organizations that can't update, or that run PHP 8.1 or earlier (which get no fix), should take PHP-based systems offline until they can. The NSA and NCSC said the same.
A WAF is a seatbelt, not a fix. CISA says one "may provide some protection until systems are updated." AWS, Cloudflare and Akamai shipped managed rules. Use them while you patch, not instead of patching.
Find every place PHP hides. It's under hosting panels, control panels, monitoring tools and appliances that never mention it. Sophos told the BBC the hard part isn't patching, it's finding every instance where PHP is running. OpenAI released a version checker as a Codex skill if you want help inventorying.
Check whether someone got there first. Amazon reports active exploitation attempts. Wiz's blog lists the tells: unusual multipart requests followed by memory-limit errors, repeated HTTP 500s, weirdly large or malformed PHPSESSID cookies, and unexplained PHP worker restarts.

The bigger question

Wiz framed PHP2Shell as a Heartbleed or Log4Shell moment for the AI era, and I think that's right, but for a different reason than most coverage says. Those bugs taught us the internet runs on shared infrastructure nobody audits. This one teaches us that "too hard to exploit" was never a security property. It was a labour cost, and AI just made that labour cheap.

OpenAI says it expects similar findings to increase sharply in the coming months. I believe them. The open question is who finds the next one first, and how wide the Defender's Window stays when both sides have the same models.

What do you think: does the window hold, or was this the widest it will ever be? And if you run PHP anywhere, how painful was your Wednesday?

Sources: Wiz Research, OpenAI, php2shell.com, CISA, NSA, BBC, Ars Technica / FT, TechCrunch, Tom's Hardware, AWS Security Blog. Wiz's announcement post: https://infosec.exchange/@wiz/117479149813368302