AI found the flaw. AI helped exploit it.

On 21 October, the UK’s National Cyber Security Centre published advice that organisations rarely see in writing:

”If you cannot patch, and you cannot mitigate, take the system offline.”

The subject was PHP — the language quietly running a large share of the web, from WordPress blogs to Wikipedia to online shops. Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, between them allow request state to survive in ways it should not, and under certain conditions permit unauthenticated remote code execution. The NCSC’s position is that every version of PHP is affected.

Within hours, Dutch and Finnish government services went dark, Danish IT supplier Kombit pulled multiple platforms including the national school communications system, and Wikipedia took parts of its site down. Amazon reported detecting exploitation attempts. Security firm Wiz put the exposure at “roughly 70% of the internet”, a figure the BBC noted it could not verify; Professor Alan Woodward of the Surrey Centre for Cyber Security told Radio 4 the realistic number was “something like 30 million websites”.

That is the incident. The more interesting story is how it was found, and what happened next.

The part that should have been good news

The underlying bug was spotted by humans at the PHP Foundation in 2024. They could not work out how anyone would actually exploit it, so it sat there.

In July 2026 the Foundation joined OpenAI’s Patch the Planet initiative. By August, researchers at Calif, Wiz and OpenAI, using frontier models, had found a working attack chain. The PHP Foundation’s own description is worth sitting with:

”A complex chain of steps at the edge of what human researchers could practically achieve.”

As UNSW Sydney’s Salil Kanhere put it:

“The underlying bugs weren’t new. What changed was our ability to find them.”

This is the strongest case anyone has made for AI in defensive security. Not a vendor claim. A decades-old flaw in critical infrastructure, invisible to skilled humans for two years, surfaced and patched.

The part that wasn’t

Basic details leaked on social media before the patch shipped. Calif then, by its own account, mistakenly published a video showing how the flaws could be used. The video came down; it had already been shared across hacking forums.

What followed is the line that should concern every risk function. According to researchers, criminals began using AI to “vibe code” working exploits — turning partial information into functioning attacks at a speed that no previous disclosure incident has had to account for.

OpenAI’s own blog post makes the point without flinching:

The incident “highlights how AI can uncover security flaws” and also how it can “help attackers rapidly develop offensive tools and exploits”.

Same capability. Both directions. Days apart.

The failure was governance, not technology

Here is what makes this a risk story rather than a security story.

The AI worked. The patch worked. Coordinated disclosure — a human process, with human controls, run by competent people who had done it many times before — is what broke. A leak, then an accidental publication, and a carefully sequenced remediation turned into a global scramble.

Every organisation now reaching for its PHP inventory is dealing with the consequences of a control failure two steps removed from its own estate. And most of them do not have that inventory, because PHP is rarely something you chose. It arrives inside an appliance, a vendor platform, a service you bought for something else. NCSC-NL has had to publish a list of potentially affected products, which tells you how much of this exposure is fourth-party.

Three questions follow, and none of them belong to the security team alone.

1. Can you answer “where is PHP in our estate” today? Not in your code. In the things you bought.
2. Who decides to take a revenue-generating system offline? The NCSC has said it may be necessary. That is a commercial decision, made under time pressure, with incomplete information. If the answer is “we’d escalate”, escalate to whom, and how fast?
3. What is your assumed window between disclosure and exploitation? If your incident response plan was built on days, this week suggests hours.