OpenAI's AI Built 948 Working Linux Root Exploits in One Run

OpenAI published a research post today, A thousand fewer paths to root, describing a pipeline that — running on an unreleased, "upcoming" model — turned thousands of candidate Linux kernel bugs into 948 distinct working local-privilege-escalation exploits in a single run against the latest kernel. The headline number is designed to alarm, and it will. But the number that should actually change how you plan is quieter and sits further down the post: each working exploit cost about $1,279, and on a hardened benchmark the whole thing ran net profitable. Vulnerability discovery and weaponization just moved from a craft to a line item.

Developing story — first published 10:16 CET (09:16 UTC), November 5, 2026. Updated as OpenAI and the kernel maintainers publish more.

What OpenAI actually did

The run happened in mid-October 2026 against the current Linux kernel, with target VMs built with Kernel Address Sanitizer and running the standard hardening a stock desktop distribution ships (SMEP, SMAP, KASLR, hardened usercopy). It was a funnel, not a magic trick, and every stage sheds volume:

Stage	Output	Time
Scope the attack surface	~5,034 audit targets (~2.8M LoC, ~7% of the kernel)	—
Discovery	2,308 candidate bugs	~12 hours
Triage / reproduction	1,724 reproduced (74.7%)	~30 hours
Exploitation	291 info-leak PoCs + 1,169 root exploits → 948 distinct bugs	~10 days total

The 948 is a de-duplicated count: variant analysis collapsed 1,169 working root exploits onto the distinct underlying flaws, one per patch that would close it. Along the way the agents reportedly used at least 10 kernel-exploitation techniques that third-party experts said were new to them — details withheld "for safety reasons." As the team put it, the hard part was not what you'd expect:

The operational challenge "was not discovery, but determining which findings could be reproduced."

The number that matters is the price

A single lab producing 948 root exploits is a headline. A single lab producing them at a unit cost you could put in a budget is a change in the threat model. The October run cost $1,213,430 in API credits — which OpenAI frames as an upper bound, the eval bill, not an all-in research cost. Most of it, $775,929, went to the exploitation stage; a successful exploit averaged about $360, with the long tail of spend burned on hard-to-trigger race conditions.

Then the economics check. On an adapted version of Google's kernelCTF — a genuinely hardened target — a 112-hour run costing $32,936 produced 21 privilege-escalation exploits, which OpenAI estimates at roughly $1.5M in potential rewards against the 26 zero-day LPEs kernelCTF accepted in all of 2026. Apply standard bounty payouts (Pwn2Own at $20,000, TyphoonPWN at $70,000) to the 948 and you land at a hypothetical $18.9M–$66.3M — 16x to 55x the run's cost. The dollar figures are hypothetical and self-reported. The direction is not.

What this is not

The honest version of this story is less cinematic than the headline, and the honest version is the one you should plan against.

• These are local privilege escalation, not remote code execution. The exploits assume the attacker already has an unprivileged account on the box. They do not, by themselves, get anyone in from the internet. What they do is make the second half of every intrusion — foothold to root — cheap and abundant.
• 948 distinct patches is not 948 shipped fixes. At publication the tally was 61 fixed upstream, 43 with staging patches, and 299 being reported and discussed. The rest are in the queue.
• Agent-reported success is not success. In an early run the pipeline claimed 200 working exploits; human review found 20 of them had reached root through a different bug than the one assigned. OpenAI's fix was an independent check that each exploit actually uses its assigned vulnerability. That correction is the most useful sentence in the whole post, and we'll come back to it.
• The model isn't released. It's described as "upcoming." But OpenAI's own forward-looking line is the part to take seriously: within a few years, they expect "even less capable models may be able to develop exploits once disclosed."

OpenAI's blunt framing for defenders: on an unpatched system, a low-privileged account should be "considered functionally equivalent to root access for a well-resourced threat actor." That has quietly been true for years. What changed is that "well-resourced" now means a seven-figure API bill, not a national lab — and the skeptics who read the post carefully land in the same place: finding bugs is becoming cheap and systematic, so the advantage goes to whoever runs the pipeline against their own code first.

Remediation

There is no single CVE to patch here — the output is a class of fresh kernel LPEs flowing to maintainers over weeks. So the response is a posture, not a KB number.

1. Treat kernel LPE patching as a fast lane, not a maintenance window. Once a flaw is disclosed and weaponizable by a cheap model, your exposure window is the gap between the maintainer's commit and your reboot. Track the stream of upstream fixes landing now (61 upstream, 43 staging) and get a kernel-update + reboot cadence that measures in days for internet-exposed and multi-tenant hosts.
2. Shrink the "already has a local account" surface. These exploits need a foothold. Assume every unprivileged service account, every web-app RCE, every CI runner and every shared host is one bug away from root — because that bug is now mass-produced. Minimize local accounts, isolate tenants, and don't run untrusted workloads next to anything you care about.
3. Sandbox what you can't trust. OpenAI's own recommendation is isolation — Firecracker, gVisor and equivalent — to cap the blast radius when (not if) a kernel bug gets exploited under you. If you run multi-tenant compute, this is the control that survives the patch gap.
4. Rescan your own old code with new tools. The same pipeline that finds these bugs for an attacker finds them for you. Code that passed a human audit in 2022 has not been audited by a 2026 model. Assume the backlog is there and go looking before someone bills $360 to find it for their own purposes.
5. Treat AI-written patches as drafts. OpenAI notes its generated fixes "needed iteration to be minimal, convention-following, and variant-complete." A patch that compiles is not a patch that's correct or complete. Review AI remediation the way you'd review a junior engineer's first kernel patch.

What is not known yet

• Which specific bugs the 948 are, and how many overlap flaws already known or already fixed — technical detail is withheld.
• The model's name and release date — it's "upcoming," with no public access stated.
• How much the published economics hold outside OpenAI's own infrastructure — the cost figures are self-reported and framed as an upper bound.
• Whether any of this has been reproduced by an independent party. The only outside voices so far are the unnamed kernel experts who confirmed the techniques were novel.

Who should be running this pipeline first

The quiet lesson in OpenAI's post is not that AI can write exploits — we have covered that before. It's that the discipline around the AI is what makes the output trustworthy: the triage stage that reproduced bugs in isolated VMs, and above all the independent check that each exploit used its assigned vulnerability — the fix for the 200-claimed, 20-misattributed error. An offensive engine without that validation layer produces confident garbage.

That validation layer is exactly what an autonomous AI red team run on your own estate is built around. Zero Hunt's engine runs a coordinated 10-agent swarm whose exploits are written per target by local models — every skill backtested in the AI Gym against corpora like Vulhub and kernelCTF-style benchmarks before it touches a production campaign, so the thing that reaches your network is validated, not self-reported. Exploitation runs inside ephemeral, gVisor-hardened containers, the appliance host never in the blast radius; a human approves anything that matters, and every finding is signed at write time. It runs on-premise on private models — no per-token meter to make a seven-figure run a budget question, and no third party that can throttle or switch the capability off. Point that engine at your own code before a cheap model, pointed by someone else, points it at you.

And when it surfaces a fresh path to root, the second question — which of these do I fix first? — is the one most teams drown in. Zero Hunt's AI Remediation Advisor ranks findings by real exploitability (CISA KEV, then what was actually proven exploitable in the campaign, then CVSS, then EPSS), hands over the exact fix with rollout and rollback notes and a compensating control for the hosts you can't patch tonight, then re-verifies the fix with the same exploit that demonstrated the issue — so "we patched it" is shown, not hoped. In a week where 948 fresh paths to root just got mass-produced, the teams that win are the ones who can prove which doors they've actually closed.