OpenAI's agents found 948 Linux kernel root exploits for $1.2M, and 1 in 10 early 'successes' used the wrong 0-day

OpenAI says an autonomous pipeline built by its security team found, exploited and wrote candidate patches for 948 local privilege escalation (LPE) bugs in the Linux kernel in a single run, for $1,213,430 in API credits. The write-up, "A thousand fewer paths to root", was published on November 4. The model doing the work is not one you can use: OpenAI calls it only "an upcoming cyber model". Its current security model, GPT-5.6 Cyber, is available only to separately approved defenders through the Daybreak Red tier. Clint Gibler, who leads cyber at OpenAI, credited his colleague @ky1ebot with building the pipeline.

The headline number is the least interesting part. The post is unusually detailed about cost per stage, failure rates and what went wrong, and those details say more about where AI bug-hunting is now than the 948 does.

The funnel

The pipeline ran against the latest kernel master branch in mid-October, in five stages, with a human security researcher reviewing the output at the end. OpenAI's own figures:

The stage costs add up to the stated total within a few dollars. The 1,169 exploits shrink to 948 after variant analysis, because several exploits can share one underlying bug, and 948 is the number of distinct patches. That gives the $1,279 per LPE OpenAI quotes. The "commonly used Linux distribution" the exploits ran on is not named.

Two numbers stand out. Only 3.1% of the candidates turned out to be wrong analysis by the model, where the reported bug depended on an impossible condition; most of the unreproduced quarter needed elevated privileges or involved races and allocation failures the agents couldn't trigger in time. And exploitation, not discovery, is where the money went. The 69 LPE candidates the agents failed to exploit cost $3,922 each on average, against about $360 for a success, so those 69 failures ate roughly $270,000, close to 40% of the LPE exploitation budget. OpenAI's own conclusion is that a give-up rule ("no progress for one hour") would have cut that sharply, and that the costs it reports should be read as an upper bound.

Root through the wrong door

The most useful section is about a mistake. In an early run, the exploitation stage reported 200 successful exploits. Human review found that 20 of them had reached root through a different 0-day than the one the agent had been assigned. The pipeline checked for a root shell, the agents got one, and in one case in ten the path didn't match the report.

OpenAI added an independent check that each exploit uses its assigned vulnerability. The broader lesson, in its words: "verify the path to a result in addition to verifying the result itself". That applies well beyond kernel exploits. Any agent evaluation that scores only the end state is open to the same failure.

Another detail in the same spirit: while working in Google's kernelCTF setup, an analyst agent hit an unexpected crash, traced it to a bug in QEMU's TCG emulator without access to QEMU's source code, and the ExploitDev agent then turned it into a privilege escalation. The bug was already fixed upstream, just not in the QEMU release the test environment used. OpenAI says it has since disclosed and patched vulnerabilities in Kata, Moby/Docker, gVisor "and other projects" found while testing its own infrastructure.

Stronger model, thinner harness

The post also reruns a comparison that matters to anyone building agents. With GPT-5.5 Cyber, giving the agent a curated library of 103 known kernel exploitation techniques raised the success rate on 63 candidates from 76.2% to 88.9%. With GPT-5.6 Cyber, a plain setup without that library beat the scaffolded GPT-5.5 Cyber, and adding the library back gained only 1.5 points. OpenAI dropped the heavy orchestration.

Across model generations the gap is large too. A July run with GPT-5.6 Sol found and exploited 166 unique LPEs for $513,690, about $3,094 each. The October run found 948 for $1,280 each, more than five times as many, which OpenAI notes came despite three months of hardening between the two scans.

What to discount

Some of the post's framing deserves less weight than its numbers.

The "$18.9M–$66.3M" valuation multiplies all 948 bugs by historical Pwn2Own ($20,000) and TyphoonPWN ($70,000) bounties for a Linux kernel LPE. Contests pay for a handful of entries, not for a thousand; nobody was ever going to pay that sum. It is a way of saying "cheap compared with what humans charge", not a market price.

The kernelCTF comparison, 21 LPE exploits against the 26 confirmed 0-day LPEs the program has accepted all year, comes with a footnote: OpenAI ran the latest kernel and dropped the SLAB_VIRTUAL mitigation from kernelCTF's configuration because it wasn't compatible. That is one of the hardening features that makes the target hard. None of the 21 is reported as submitted or accepted, and the "$1.5M bounty, ~45x the cost" is again conditional.

The "at least 10 novel exploitation techniques" were found in a sample of 166 exploits and checked with outside kernel exploitation experts, but the details are withheld for safety reasons, so readers can't judge them.

The maintainers' side

OpenAI says that during the ten days of the scan and analysis, 61 of the LPEs had already been patched upstream by other people, 43 had patches in staging and 299 were being discussed publicly. Following the kernel community's suggestion to start with critical bugs, it has sent "hundreds" of reports with patches, and is feeding the rest through its Patch the Planet partners. OpenAI also admits its first patches were functionally correct but sometimes larger than needed, off-style for the surrounding code, or blind to variants of the same bug; extra instructions and iteration fixed most of that.

That matches what maintainers elsewhere are describing. Last week PostgreSQL committer Robert Haas blamed LLM bug-finding for a late PostgreSQL 19, with commits to the release branch up 61% and fixes to the previous stable branch up 75% in a year. OpenAI's numbers suggest the kernel is under the same kind of pressure: by its count, 403 LPEs had been patched, staged or publicly discussed by other people by the time its own scan and analysis finished.

Its practical advice is blunt: for now, a low-privileged account on a Linux machine that isn't fully patched "should be considered functionally equivalent to root access for a well-resourced threat actor". It recommends isolation with tools like Firecracker and gVisor to limit the damage, and, as the QEMU episode shows, that layer gets audited by the same agents too.