The bugs were there for a decade. AI finally read the code.

At a glance: the autumn cases

PHP2Shell: the out-of-memory error nobody feared

Start with the strangest one. For years, PHP had a known, slightly boring problem: when a request ran out of memory, the cleanup that followed could leave the engine’s internal state in a mess. A PHP core developer had spotted the underlying issue in a 2024 audit. It stayed on the pile, because nobody could show it was actually exploitable — and an unexploitable bug, in a project drowning in reports, is a bug that waits.

AI did not wait. In August, three groups converged on the same root cause independently. Calif, auditing PHP under OpenAI’s Patch the Planet programme, reported an exploitable path on 11 August. Wiz, using its Atlas tooling alongside Gemini 4 Argon and GPT-5.6 Sol, found its first flaw on 19 August, had code execution against Drupal the next day and WordPress the day after, and reported on 24 August. What they had, collectively, was four memory-safety bugs — use-after-free flaws and an OPcache type confusion, all triggered by how PHP tidies up after a fatal error — grouped under two CVEs, both scored 9.2.

The uncomfortable part is the blast radius. PHP runs roughly 70 per cent of websites whose server-side language can be identified. The flaws live in the runtime itself, so they sit underneath every plugin and every line of application code; Wiz’s line, repeated everywhere since, is that even a “Hello World” page was enough. One variant could also read a worker’s memory and hand back other people’s passwords, tokens and API keys inside a session cookie. Fixes landed on 21 October in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — a day early, after the CVE identifiers leaked — and four engineers had spent about two months on the patch. Amazon’s honeypots, meanwhile, had recorded an exploitation attempt on 17 October. Four days before disclosure.

“An embargo protects defenders only until someone else finds the same bug.”— Wiz Research, on PHP2Shell, October 2026

That sentence is the whole story in miniature. Coordinated disclosure assumes the finder is roughly unique. When three teams — and, apparently, at least one attacker — can all reach the same bug in the same few weeks, the quiet period stops being a safety margin and starts being a head start for whoever moves first.

Linux: 948 ways to root, and one very old TCP bug

If PHP2Shell was about depth, OpenAI’s kernel run was about sheer throughput. Published on 4 November under the title “A thousand fewer paths to root”, it describes a pipeline of specialised agents let loose on the security-sensitive parts of the Linux kernel: scouts picked 5,034 audit targets covering about 2.8 million lines of code, triage agents reproduced suspected flaws in virtual machines, and exploit agents then tried to turn them into working privilege escalations against a stock system with the usual protections — SMEP, SMAP, KASLR — switched on.

Some perspective helps here. These are local privilege escalations: an attacker needs a foothold first, so this is not 948 remote doors into every Linux box. But a foothold is exactly what PHP2Shell provides, and reports already describe the two being chained to reach root. Ten days after the run, OpenAI said 61 of the flaws were patched upstream and hundreds more were in reporting. In July, the previous model had found 166 such bugs. Five times the yield, three months later, against a kernel that had been hardened in between — that trajectory, more than any single number, is what should worry maintainers.

Anthropic’s contribution was smaller and, in its way, sharper. On 27 October its Frontier Red Team described five exploit chains built by an unreleased Claude model, covering Chrome, Safari, Android, Windows and Linux. The Linux one targeted CVE-2026-98432, a race-condition use-after-free in TCP connection handling introduced in kernel 4.4 — in 2016. Against a server running a multipath TCP listener, the model leaked a kernel address to defeat KASLR, then reused the same bug to run commands as root. Forty-eight minutes for the leak, five more for the shell. The upstream fix — four lines — had landed on 15 October, yet days later Ubuntu still listed its kernels as vulnerable and Red Hat was only just raising the bug to Critical. Discovery is now fast. Distribution, apparently, is still distribution.

And then there is Vghost, found by Tencent Zhuque Lab’s Corvus AI system and written up on 12 October: a flaw in the kernel’s vhost subsystem, created when two reasonable changes from kernels 4.11 and 5.9 combined badly, and left in place for close to a decade. Either change alone was fine. Together, they gave a local user kernel read/write — and, in one setup, a route from a guest virtual machine to its host. No single human reviewer ever held both changes in mind at once. An agent, trawling the whole history without getting bored, did.

cPGuard: when the guard itself is the door

cPGuard belongs in this article for a different reason, and it is worth being precise about it: there is no evidence its compromise was an AI discovery story. What happened, per OPSSHIELD’s own disclosure on 3 November, is a supply-chain attack. An attacker registered a trial account, reached the company’s billing and licensing server, stole an update-storage key, and pushed a fake cPGuard update through the channel customers trust by default. For 72 minutes in the early hours of 2 November, versions 5.88.12 to 5.88.19 were served to servers that updated automatically. About 2,950 of them ran the script — as root, because a security agent runs as root.

The script did what you would fear: it read /etc/shadow, SSH keys, database credentials and shell histories, packed them into an archive, and left behind a hidden setuid-root shell and a cron job. Billing data for roughly 7,900 accounts was also exposed. The clean release, 5.88.26, removes the backdoor — but, as responders were quick to point out, removing the malware does not un-steal a private key. Anyone affected has a rotation problem, not just a patching problem.

Why include it alongside the AI cases? Because it is the other half of the same squeeze. Defenders are being told, correctly, to patch faster than ever, because AI has shortened the distance between a bug existing and a bug being exploited. But patching fast means trusting update channels completely and automatically — and cPGuard is what that trust looks like when it is abused. Speed and trust now pull in opposite directions, and nobody has a clean answer for that yet.

The part that actually changed: the economics

Strip away the headlines and three things have genuinely shifted. First, finding bugs in old, widely reviewed code is no longer scarce labour. The scarce labour is triage: PHP’s maintainers handled 15 CVEs and more than 100 invalid or duplicate reports in the same period, and kernel maintainers have warned openly about the burden of AI-generated reports. Second, exploiting a bug — historically the expensive, artisanal step, the reason a 2024 PHP curiosity could safely sit in a pile — is collapsing in cost. Two weeks for Calif’s researcher to reach remote code execution. Fifty-three minutes for Anthropic’s model. About $1,279 per validated kernel flaw for OpenAI. Third, the window after disclosure is shrinking from the other side: Google observed one AI-found BeyondTrust flaw, CVE-2026-1731, being exploited by a threat cluster within four days of disclosure, and by five more within a week.

For developers, that adds up to a new kind of pressure. “Nobody would bother exploiting that” — the quiet assumption underneath a decade of deferred fixes, odd edge cases and memory-unsafe legacy code — is no longer a safe assumption. Agents bother. They bother at 3 a.m., across the entire history of your repository, without prioritising the parts you would prefer they looked at. The honest counterweight is that the same tooling is producing patches, not just exploits: 948 candidate kernel fixes in one run, AI-assisted validation of the PHP patch, coordinated pre-disclosure briefings for PHP2Shell that had mitigations ready on day one. Developers are on their toes partly because attackers got faster, and partly because, for the first time, defenders can plausibly keep up — if their patching, testing and update infrastructure can move at the speed the findings now arrive.

Timeline: September to November 2026

The discussion online

The reaction split, predictably, between “this changes everything” and “read the methodology”. Both threads are worth following — these are the posts and write-ups that shaped the conversation, with the reporting behind each card linked.

What to do this week

None of this asks for panic. It does ask for a shorter to-do list, done sooner. Tap each item as you clear it — the counter is just for this visit.

Tick them off as you go — PHP, kernel, cPGuard, secrets, and backups.

• PHP: move every host to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. If you are on 8.1 or older, there is no official fixed release — plan the upgrade, and use the interim mitigations in the PHP advisories meanwhile.
• Kernels: confirm your distribution’s kernel includes the fixes for CVE-2026-98432 and CVE-2026-74580 — do not assume “upstream fixed” means “installed”. Check Ubuntu and RHEL status explicitly; both lagged.
• cPGuard: if any server installed an update on 2 November, update to 5.88.26, check for /var/tmp/.cpg91511_sh and /etc/cron.d/i93677, and rotate root SSH keys, database passwords and any secret that lived on the box.
• Exposure: inventory multipath TCP listeners and forgotten PHP — containers, appliances and that one WordPress install — before someone else’s agent inventories them for you.
• Process: shorten your patch window for critical runtime and kernel flaws, and rehearse secret rotation. Four days from disclosure to exploitation is now a documented case, not a hypothetical.

The old bugs are not going to stop coming; if anything, the autumn’s run-rate says the backlog of “known but unexploitable” is going to be worked through in public, one agent-run at a time. The teams that come out of this well will not be the ones who found a way to ignore it. They will be the ones whose boring machinery — inventories, update channels they actually verify, rehearsed rotations — was ready before the interesting news arrived.