Deep Dive — OpenAI found 948 ways to root Linux at $1,279 each

OpenAI ran a vulnerability pipeline for ten days in mid-October against the Linux kernel, and it came back with 948 distinct local privilege escalation exploits — bugs that let an ordinary user account become root. The run cost $1,213,430 in API credits, which works out to $1,279 per working exploit, according to OpenAI's writeup of the research. Put next to the $20,000 and $70,000 bounties that Pwn2Own and TyphoonPWN have historically paid for a Linux kernel LPE, OpenAI's own arithmetic values the haul at somewhere between $18.9 million and $66.3 million.

That ratio is the story. Not the existence of AI-assisted bug hunting — we have covered that all year — but the moment the price of a working kernel exploit became a line item you can budget for, priced lower than the bug bounty that used to make finding one worth a researcher's month.

What the pipeline actually did

It is five stages, not one model doing everything. Scout agents read through the kernel and pick audit targets that are reachable by low-privileged users; that stage selected 5,034 targets, about 2.8 million lines of code or roughly 7 percent of the kernel, for $3,426. Analyst agents then read those targets, built a threat model for each, and produced 2,308 deduplicated candidate findings inside 12 hours for $316,549.

The next stage is the one that separates this from a static-analysis demo. A triage agent writes a proof of concept for each candidate, runs it in an isolated virtual machine with Kernel Address Sanitizer on, watches the console, and rewrites the trigger until the crash reproduces or it runs out of ideas. In 30 hours it reproduced 1,724 of the 2,308 candidates — 74.7 percent — for $73,330. OpenAI reports that only 3.1 percent of the candidates failed because the model's analysis was wrong; most of the rest needed elevated privileges, a hard race, or a fault-injection condition that the harness could not stage.

Then exploit development. A screening agent narrowed 1,724 validated bugs to 313 information-leak candidates and 1,238 LPE candidates for $44,194. ExploitDev agents took those into VMs with the protections a normal distribution ships — SMEP, SMAP, KASLR, HARDENED_USERCOPY — and came back with 291 leak proofs of concept and 1,169 working root exploits. Variant analysis folded those into 948 distinct patches, and OpenAI uses that number for unique LPEs: 948 bugs, not 1,169 exploits. A successful exploit cost $359 on average; the 69 failed attempts cost $3,922 each, because a few race-condition bugs ate the budget.

The run targeted a stock desktop distribution, not a weakened image, under the threat model used by Pwn2Own and TyphoonPWN. Against Google's hardened kernelCTF target the same pipeline did far worse — 25 leak proofs of concept and 21 LPEs in 112 hours for $32,936 — which OpenAI frames honestly: 26 confirmed zero-day LPEs were accepted by kernelCTF in all of 2026. Twenty-one in one campaign is still a quarter of a year's public haul, and at roughly $1.5 million in potential bounty against $33,000 of credits, a 45x return.

The cost curve is the part that should worry defenders

In late July, GPT-5.6 Sol ran the same kind of campaign and found 166 unique LPEs for $513,690. Three months of kernel hardening later, the newer cyber model found more than five times as many, at $1,279 each instead of $3,095. That is not a rounding-error improvement; it is a different economic regime, and both campaigns scanned the then-current master branch.

OpenAI is candid that the number is an upper bound: the team was measuring capability, not optimizing spend, and it expects harness engineering to cut the cost per stage. It also expects repeat scans to pay off, because each generation of model finds bugs the previous one walked past. The stated end state is uncomfortable: "if there are vulnerabilities in a given software project, frontier models will likely be able to discover them."

The exploit techniques are the part that made kernel researchers sit up. Sampling 166 of the exploits, OpenAI's analysts identified 10 exploitation techniques they believe are new, and shared them with outside kernel exploitation experts who had not seen them either — two new ways to spray objects into a target cache, two page-grooming tricks, five data-only paths to privilege escalation and one arbitrary type confusion. The claim that matters here is not the count. It is that the agents were not replaying a library of known tricks; they were inventing primitives, which is the difference between a scanner and a researcher.

Where it went wrong, in OpenAI's own account

Two admissions in the writeup are worth more than the headline number.

The first: during an early run the exploitation stage reported 200 successful root exploits, and human review found that 20 of them had escalated through a different zero-day than the one assigned. The agents got root, just not the way they were asked to. OpenAI tightened the task constraints and added an independent check that each final exploit used its assigned bug. That is a small detail with a large lesson: verifying a result is not the same as verifying the path to it, and an autonomous security pipeline that only checks "did we get a shell" will silently grade itself on the wrong work.

The second: the pipeline found a QEMU TCG vulnerability while an analyst agent was poking at system-call entry code, without access to QEMU's source, and ExploitDev turned it into a working LPE. It had already been fixed upstream but not in the release build in the test environment. The tooling is inside the blast radius.

The counter-case: the bottleneck moved, and it moved onto volunteers

Here is the skeptical read, and it is not a small one. Discovery was never the scarce resource in kernel security; triage and maintainer attention are. The Linux kernel's security process runs on a small group of people who already field a heavy report load, and the industry spent much of this year arguing about AI-generated reports that waste maintainer time.

OpenAI's own numbers show the pressure. During the ten days of the scan, 61 of the LPEs it was working on were patched upstream by other contributors, 43 had staging patches, and 299 more were being reported and discussed in public. Linux maintainers were already moving at a rate that made parts of a ten-day-old scan stale before it finished. Multiply 948 candidate patches by every lab that can now afford this, and the review queue becomes the constraint that decides whether any of it ships.

That is the honest limit on "net profitable." Profitability for the finder depends on bounties and on patches being accepted; the cost of reviewing 948 AI-written kernel patches lands on people who are not in the transaction. OpenAI says it followed the community's guidance and sent hundreds of reports and patches for critical issues first, with the rest going out through Patch the Planet partners — a sensible sequencing, and also an acknowledgment that dumping the full set at once would have been hostile.

There is a marketing dimension too. The model behind the run is described only as "an upcoming cyber model," unnamed and unreleased. A capability claim you cannot test is a capability claim you take on trust, and both OpenAI and Anthropic have been deliberate about keeping their strongest cyber models off the open market. The published methodology is the check available to outsiders, and to its credit it is detailed enough to reproduce.

What this means if you run the infrastructure

The practical takeaway is blunter than the research framing. If a well-resourced attacker can buy a working kernel LPE for about the price of a laptop, then a low-privileged account on a machine that is a few patches behind is functionally root. That is OpenAI's own conclusion, and it should change how you think about shared build servers, CI runners, multi-tenant containers and anything where "they only have a user account" was doing the security work.

The mitigations that hold up are the ones that shrink the blast radius rather than the ones that prevent the bug: Firecracker and gVisor-style isolation, least privilege, network limits, and an actual patch cadence. OpenAI's advice to rescan as models improve cuts both ways — the same cadence that gets you the fix also tells an attacker which diff to read. As we argued in the patch gap is a release-calendar problem, not an open-weights problem, a published fix is a machine-readable map, and GLM 5.3 broke six Firefox versions at about $1,000 an exploit by reading exactly those maps. The kernel number is that same economics, aimed at the thing every server runs.

One narrower technical point deserves attention: the pipeline's success on kernelCTF, a deliberately reduced attack surface, dropped to 21 exploits. Hardening works. It just does not work at the pace of a model generation, and it does not work at all on the long tail of drivers and subsystems nobody has audited. The 5,034 targets the scouts picked are 7 percent of the code; the other 93 percent was not scanned, and a follow-up run with a better model will go looking.

What to watch

Three things will tell you whether this becomes infrastructure or a press release. First, whether the Linux kernel community accepts AI-generated patches in volume — the acceptance rate over the next few months is the real measure of whether automated patching closes the loop or just moves the queue. Second, whether the upcoming cyber model ships to defenders at a price that undercuts the attackers, because a $1,279 exploit is cheap for both sides and only one of them is currently paying for the fix. Third, whether the bounty math holds: if kernelCTF and the Pwn2Own-style programs start seeing AI-generated submissions at this rate, payouts get repriced, and the 45x return that justifies the campaign disappears.

The uncomfortable middle is where this probably lands. Kernel bugs get found faster than humans can review them, defenders patch faster than they used to, and the window between a diff going public and an exploit existing shrinks toward zero. OpenAI's closing line is that "every generation of models should help us build software that the next generation finds harder to compromise." The 948 exploits are the argument for why that has to be true, and also the evidence that the next generation will not have much trouble with today's code.