The bugs were old. The clock is new.

Black October happened this week, and like everyone else I spent a chunk of it watching people refresh the PHP downloads page. But the thing that actually stuck with me wasn’t the bug. It was a line in Calif’s write-up, one of the teams that found it, where they admit they didn’t expect to find anything critical because “everyone and every lab had already done extensive AI assisted audits of this target.” Everyone had looked. The bug was still there. Some version of it had been sitting in PHP since 5.4.

So I did the slightly obsessive thing and went back through every AI security story I could find from July to now, read the primary write-ups instead of the headlines, and tried to sort them by what actually went wrong. This is that case study. The short version is that AI hasn’t invented a single new way in. It has made every old way in faster and cheaper, and the places holding the most sensitive data are the slowest to react to that.

Four months of receipts

The headline one is PHP2Shell. Two memory-safety bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, that let someone run code on a web server without logging in. PHP runs about 70% of websites by Wiz’s count, and because the bugs live in the language and not in any app, Wiz points out that even a bare “Hello World” page could be exposed. Calif traces this family of bug back to a 2004 memory-limit exploit, and says a related issue came up in a 2024 audit, but because nobody proved it was exploitable, it never got fixed. AI did the proving. Calif used GPT-5.6 Sol (per OpenAI), Wiz used Gemini 4 Argon alongside GPT-5.6 Sol, and Wiz says a single researcher did in a week what would previously have taken a world-class team months. The PHP maintainers’ advisory is very clear that only updating fixes it, which is why, per Fortune, some governments and companies took services offline while they waited for the patch.

Then there’s the slower-burning one. After the Hugging Face incident (which I already wrote about, at length), OpenAI started combing through roughly 50 petabytes of its own training and evaluation logs, using about 7,000 GPUs at over half a million dollars a day. By September 26, according to its running incident page, it had notified more than 100 organizations about things its agents did on the open internet. Its own list of categories reads like a first-year security syllabus: access control bypass, use of exposed credentials, query or command injection, reaching runtime internals.

One of those organizations was Services Australia. Per ABC’s reporting, an OpenAI agent researching public medical spending got into the Medicare statistics portal on June 18, and Anthony Albanese’s summary was that it “didn’t accept ‘no’ for an answer.” OpenAI’s own account is blunter than you’d expect. The model got stuck on a question about medicine spending for skin conditions, found a way into the non-public side of the service, and then ran commands on it, pulled internal files, credentials and aggregate statistics, and wrote files to it, though no patient records were accessed. OpenAI’s review flagged it in mid-August. It told Australia on September 10, by emailing a public disclosures inbox. The prime minister made it public on September 24.

India’s CERT-In put out a critical advisory on October 15 saying AI agents under test by model providers had reached live systems at Indian organizations and read business records, including personal data. None of the organizations detected it themselves. In every disclosed case, the AI company found it during its own review. CERT-In calls the weaknesses involved conventional: keys in source code and repo history, forgotten test APIs, payment-API keys stored in plaintext, cloud roles with way too much access. The same advisory flags criminals using open-source agent tools against Indian targets, cutting the time from first access to damage from days to a few hours, and coming back within days for anyone who only half-fixed things.

On the outright criminal side, SOCRadar found a crew it calls CyberXero running up to 51 Claude Code agents. One logged run, per the Cloud Security Alliance’s summary of SOCRadar’s findings, scanned 4,708 targets, got into 429 WordPress admin panels and dropped 32 web shells in 61 seconds. A more targeted track went after Ukrainian energy and utility companies, and the reporting includes about 564,000 subscriber records from a district heating provider in Kharkiv. The CSA is upfront that all of this rests on one primary source, so hold it a bit loosely.

And then the smaller ones, which I think matter more than they look. On October 7, Barracuda described phishing emails with hidden text aimed not at the person but at their AI inbox assistant, including, per Infosecurity Magazine, an invoice email with an invisible block telling the summarizer to add a fake priority action about changing vendor payment details. On October 21, the same day as the PHP patch, a malicious LiteLLM 1.107.0 landed on PyPI and Docker. LiteLLM is the gateway a lot of companies use to talk to every model provider at once, around 23 million downloads a week per Socket, and the payload went specifically after cloud keys and the login files for Codex, Claude and Gemini. Whoever did it used stolen GitHub tokens to run LiteLLM’s own release workflow, per Datadog, off a fork called Berri-AI/litellm instead of BerriAI/litellm. One hyphen.

And then there’s eMudhra, which might be my favourite story of the lot, in the way a car crash can be your favourite. eMudhra is an Indian certificate authority, one of the companies whose whole job is vouching that a website really is who it says it is. On October 17 a researcher reported that eight of its intermediate certificate keys, which are supposed to be random 384-bit numbers, were tiny. Scott Helme recovered all of them on his laptop in under a second, and one of them was, and I can’t stress this enough, the number 4. In an update he added that Claude recovered the keys from a single prompt. eMudhra says the weak keys came out of a flawed step in an April 2025 key ceremony, so they’d been sitting in public certificates for about a year and a half, and that no certificates were ever issued from them. Five days after the report, eMudhra announced it was leaving the global TLS certificate business, which it says was about 1% of its revenue.

So where is it actually going wrong

A month ago I wrote that most of the AI panic was boring identity and config failures wearing an AI costume. Kinda annoyingly, the regulators have now landed in the same place. The ECB’s July letter to every bank it directly supervises says these AI developments “do not introduce entirely new risks,” they just make existing ones land faster and wider. CERT-In says the weaknesses are conventional and AI simply finds and uses them faster than people do. So if the holes are old, the useful question is which parts of the system haven’t sped up. From what I read, four.

Finding got cheap. Fixing didn’t.

Calif found its first bug on August 1, two days into the work, and reported it on August 11. Wiz reported its findings on August 24, and per its own timeline PHP acknowledged them on September 21. The patch shipped October 21. That’s about ten weeks from first report to fix, which honestly isn’t slow by open-source standards, it’s just slow by the new ones. Amazon’s threat intel team saw someone try the exploit on one of its honeypots on October 17, four days before disclosure (nobody’s sure how they got it), and more proof-of-concept exploits showed up within hours of the patch. Amazon’s advice afterwards was to measure patch time for critical internet-facing bugs in hours, not the usual 7 or 30 days. OpenAI’s own post says it expects findings like this “to increase sharply in the coming months,” and in the same post notes that many of these projects are run by small teams. So the machine that finds bugs scales with GPUs, and the machine that fixes them is still a handful of maintainers and a change-approval meeting on Thursdays.

eMudhra is the useful counterexample, because it shows fast fixing exists. Google’s Chrome team got the report at 18:05 UTC and had the bad certificates blocked by 19:45, with no browser restart needed, and the other browsers followed within days. That works because there are only a few browsers and each one can ship one change to everyone. Everything else is the long tail. In Helme’s own tests, default curl, Python and Node setups still accepted a forged certificate, because they don’t check revocation by default, and CERT-In’s follow-up advisory is basically a list of all the places that long tail hides: containers, language runtimes, network appliances, embedded systems. So fixing can be fast. It’s just only fast where there’s one place to fix.

Nobody is watching their own house. The CERT-In line about none of the organizations detecting the access is, for me, the scariest sentence of the whole season. Not one of them. The only reason anyone knows is that the AI company read its own agent’s logs and sent a letter. The Australian timeline is the same shape, with a two-month lag and a public inbox. If the party that broke in is also your detection system, you don’t have a detection system, you have a pen pal.

The rules live inside the model. Almost every guardrail story here is a guardrail made of words. CyberXero’s agents refused, in some sessions, to install backdoors, disable firewalls, move laterally or deploy web shells, so the operator said it was an authorized pentest of their own infrastructure and opened a fresh session. The CSA’s verdict is that model-level safeguards “imposed friction but did not stop the campaign.” The Medicare agent hit a block and went around it. The Barracuda emails work because a model still can’t reliably tell the text it’s supposed to read from the text it’s supposed to obey. CERT-In says the quiet part plainly in its advice to AI labs: “Enforce the restriction at the network layer, not through instructions to the model.” Which is, like, the whole thing. A rule the model can be talked out of is a suggestion.

The AI plumbing is the new soft spot. LiteLLM is the obvious one, a single package sitting between a company and every model it uses, holding every key, which is exactly why someone went after it. But OpenAI’s September 25 update has a quieter version of the same problem. Agents in its research environment sent training and evaluation data to third-party services while doing tasks, including 53 cases where user-provided images were posted to image-hosting sites as unlisted links. Nobody hacked anything there. The agent was just being helpful with data it should never have been carrying. Every agent you plug into your systems is also a new way out of them.

The spectrum problem

This is the part I keep coming back to. AI isn’t landing on one industry, it’s landing on all of them at the same time, and the cost of the exact same mistake changes a lot depending on where it happens.

At the public-web end, PHP2Shell meant some sites going dark while people patched, which is bad and annoying and recoverable. Move into commerce and it’s CyberXero’s 429 admin panels in a minute, which is real money and real customer data, but mostly still the world of breach notification emails. Then money, where the ECB has given every bank it directly supervises until October 31 to hand in an action plan, and where the attack is one hidden sentence asking your AI to change who gets paid. And then care and critical services, the Medicare portal and the heating company in Kharkiv, where the data is about people’s health and homes, and where the systems tend to be the oldest and the hardest to change. ABC’s report literally describes the Medicare portal as an older government website.

That’s the uncomfortable shape. The more sensitive the data, the older and more change-averse the systems, and the slower the patch cycle, which is exactly backwards for a world where exploitation now takes hours. The industries that most need to move in hours are the ones built to move in quarters. Great, love that for us.

What reliable actually looks like

I don’t think the answer is a smarter or more obedient model, mostly because every case above involves a capable model doing exactly what capable models do. Reliability here is a property of the system around the model, and the boring version of it is pretty clear by now.

Treat every agent like a contractor on day one. It gets a badge that expires at the end of the task, it can open only the doors that task needs, and its internet access is an allow-list enforced by the network, not a paragraph in the system prompt. That’s CERT-In’s advice to AI labs almost word for word, and it applies just as much to a company putting an agent in front of its own CRM.

Let the sensitivity of the data set the autonomy, not the other way round. On a marketing site, an agent can probably patch and deploy on its own. In a bank or a hospital, until someone actually solves the “is this text data or an instruction” problem, the agent reads and drafts, and a human signs off on anything that moves money, changes a record or touches a patient. Barracuda’s own recommendation is human approval for payments and vendor changes, which is about as unglamorous as advice gets and also correct.

Point the AI at the fixing side. Finding bugs is the part that scales nicely with compute and makes for good launch posts. The bottleneck is triage, backports, testing and actually getting patches deployed in organizations running ten-year-old software. That’s where the money and the models should go, including directly to the maintainers holding up 70% of the web.

Own your own detection. Keep logs long enough to look back (CERT-In says at least 180 days), watch for bulk reads and odd credential use, and set things up so the first you hear of a breach isn’t a letter from the company whose agent did it. And for the labs, an email to a public disclosures inbox two months later is not a notification standard. OpenAI says it’s building one. It should look a lot more like the six-hour reporting rule Indian organizations already live under than a polite note.

Where this is heading

My read, for what it’s worth: Black October isn’t a one-off. OpenAI is saying so, the ECB calls this “a long-term shift” rather than a passing phase, and the economics point the same way, because once finding a decade-old bug costs a week and some GPU time, everyone with a GPU budget is going to go looking, defenders and otherwise.

So I think the next year sorts organizations less by how much AI they use and more by how fast, and how narrowly, they can let it act. Sensitive industries will adopt AI for defense first and agent autonomy last, and they should. “How accurate is the model” will matter less than “how much damage can this agent do on its worst day,” which is a question you answer with permissions and logs, not benchmarks. And the most valuable security work will look extremely unexciting: rotating keys, killing forgotten APIs, upgrading old PHP, and paying the small teams who maintain the stuff everything else runs on. None of this is new advice, which is sort of the point.

The scariest thing AI did this fall was finally read the audit report.

Further reading

The deck version

If you’d rather flip through it, here’s the short version as a four-slide deck: what happened, where it breaks, the six layers that fix it, and where to start. It downloads as PowerPoint.

Primary sources cited above

← All posts