OpenAI Alleges 948 Linux Root Exploits in One Run
OpenAI published a prototype pipeline that, it says, autonomously found, validated, exploited, and patched Linux kernel vulnerabilities. The headline numbers are 2,308 candidate findings, 1,724 dynamically reproduced vulnerabilities, 291 information-leak proofs of concept, 1,169 working local privilege-escalation exploits, and 948 distinct patches. OpenAI puts the run at $1,213,430 in API credits, or $1,279 per unique LPE.
Those numbers are OpenAI’s. The post does not publish a list of CVE IDs, commit hashes, or exploit code. The model is described only as an “upcoming cyber model.” No independent audit is published with the post, and OpenAI does not report how many of its patches Linux maintainers accepted. The capability claim is significant, but the unverified parts should be read as alleged.
The Pipeline OpenAI Built
The pipeline has five stages. Scout agents pick security-relevant code that a low-privileged user can reach. Analyst agents scan those targets for candidate bugs. Triage agents try to reproduce each candidate in an isolated virtual machine with Kernel Address Sanitizer (KASAN). Exploit-development agents test whether a reproduced bug can leak information or escalate to root. Patch-generation agents write candidate fixes. Human researchers review the exploit, patch, and severity before reporting.
The scouts selected 5,034 audit targets covering about 2.8 million lines of code, roughly 7% of the kernel. The analyst stage produced 2,308 candidates after deduplication in about 12 hours, for $316,549 in API credits. The validation stage reproduced 1,724 of them, about 74.7%, for $73,330. The exploit stage produced 291 information-leak proofs of concept and 1,169 working LPE exploits before variant analysis reduced the set to 948 distinct patches. The total run cost $1,213,430.
The reported target was a stock desktop Linux distribution with standard protections such as SMEP, SMAP, KASLR, and HARDENED_USERCOPY enabled. The validation VMs used KASAN. The exploitation stage used isolated VMs and required a root shell before marking an exploit successful. The post does not name the distribution, the kernel version, or the full VM configuration.
The scan observed 61 LPEs patched upstream, 43 with staging patches, and 299 being discussed publicly during the 10-day window. Reporting began with critical vulnerabilities, with Patch the Planet partners handling the rest, according to the post. Those are observations about kernel activity, not a public ledger tying each of the 948 findings to a specific upstream commit.
Where the 948 number comes from
The 948 is not 948 CVEs, and it is not 948 independent remote exploits. OpenAI uses it as the count of unique LPEs after variant analysis, with one candidate patch per unique bug. The exploit stage reported 1,169 working LPE exploits. Those are different metrics, and the post sometimes uses “LPE exploits” and “unique LPEs” close together.
That distinction matters for judging the claim. A variant analysis can collapse many exploits into one root cause, or split one root cause into several patches. Without the underlying list, an outside reviewer cannot check the deduplication, the patch boundaries, or whether the 948 are distinct security boundaries rather than variants of the same bug.
A 3.1% share of the failed candidates came from incorrect model analysis. The rest mostly failed because they required higher privileges, depended on difficult race conditions or allocation failures, or ran out of time. That is a useful disclosure. It shows the pipeline is not a vulnerability oracle; it is a triage system with a meaningful false-positive rate.
The kernelCTF Run
A second campaign ran against an adapted kernelCTF environment, a hardened kernel with reduced attack surface. The pipeline produced 25 information-leak proofs of concept and 21 LPE exploits in 112 hours for about $32,936 in API credits, according to the post. That compares with 26 confirmed 0-day LPEs accepted by kernelCTF in 2026.
If the 21 vulnerabilities were accepted by the program, the bounty would be around $1.5 million, roughly 45 times the scanning cost. That is a conditional calculation. The post does not say the 21 were accepted, and it does not publish the submissions or the program’s responses.
The agents discovered and used at least 10 novel Linux exploitation techniques, according to the post. The categories are two persistent elastic objects for kernel-cache spraying, two page-grooming techniques, five data-only techniques, and one arbitrary type confusion. The techniques were shared with third-party kernel exploitation experts and were new to them. The technical details are withheld for safety, so the novelty claim is alleged rather than reproducible.
There is a side finding that deserves attention. The pipeline found a QEMU TCG vulnerability while analyzing system-call entry code, without access to QEMU’s source, according to the post. The bug was fixed upstream but not in the release build used during the run. No CVE or public QEMU advisory is linked in the post.
What OpenAI itself caught
One of the most important details is a failure the researchers disclose. In an early run, the exploitation stage reported 200 successful LPE exploits. After human review, 20 of them had obtained root through a different 0-day than the one assigned to the agent. OpenAI tightened the constraints and added an independent check that each exploit used its assigned vulnerability.
That is a concrete example of why the pipeline needs verification. A root shell proves that some vulnerability was exploited. It does not prove that the intended vulnerability was exploited, or that the candidate patch addresses the path the agent used. The pipeline was tightened after the run, but the episode is a reminder that the headline number depends on the quality of the post-exploitation checks.
What is verified, and what is alleged
| Claim | Status |
|---|---|
| OpenAI built a five-stage autonomous discovery, validation, exploitation, and patching pipeline. | Published in OpenAI’s post; methodology described in detail. Not independently audited. |
| 2,308 candidate findings; 1,724 reproduced; 291 information leaks; 1,169 working LPE exploits. | OpenAI-reported internal measurements. |
| 948 unique LPEs, counted by distinct candidate patches. | Alleged. No public list, CVE mapping, or external deduplication. |
| 10 novel exploitation techniques. | Alleged. Categories described; technical details withheld; expert review anonymous. |
| 61 LPEs patched upstream, 43 staging, 299 discussed during the scan. | OpenAI-observed kernel activity; no mapping to the 948. |
| 21 LPEs and 25 information leaks in the kernelCTF environment. | OpenAI-reported; acceptance and bounty are conditional, not confirmed. |
| $1,213,430 total API cost; $1,279 per unique LPE. | OpenAI’s API-credit accounting. It excludes engineering, human review, and other costs. |
| $18.9M to $66.3M hypothetical bounty value; $1.5M kernelCTF bounty. | Hypothetical or conditional comparisons, not realized payouts. |
| QEMU TCG vulnerability found and fixed upstream. | Alleged. No CVE, commit link, or advisory published in the post. |
The $1,279 Cost per LPE
Even with the caveats, the economics are the story. OpenAI is describing a marginal cost of roughly $1,300 in API credits per unique LPE, before human review. If that number survives independent testing, exploit development becomes cheap enough to run continuously. The same capability that helps defenders find and fix bugs also helps attackers find and weaponize them.
The bottleneck moves to validation, disclosure, patch review, and deployment. A generated patch is not a merged patch. A reproduced crash is not a reliable exploit. A root shell in one VM is not proof of root on every kernel build. The 20 wrong-0-day exploits show why those distinctions are not academic.
For defenders, the practical lessons are straightforward. Keep kernels and container hosts current. Inventory kernel versions and patch levels. Treat a low-privileged local account on an unpatched host as close to root. Use sandboxes and isolation such as Firecracker or gVisor to limit blast radius. Expect more AI-generated reports, and build triage capacity that can check reproduction, root cause, and patch quality rather than counting submissions.
For open-source maintainers, the report is a warning about volume. If frontier models can generate hundreds of plausible LPE reports in a run, the limiting factor becomes human review and patch acceptance. Maintainers will need reproducible PoCs, clear root-cause analysis, and evidence that a patch closes the assigned path, not just a crash.
What to watch
- CVE assignments and kernel commits. A public list of the 948, or a representative sample, would let outside researchers check uniqueness and severity.
- Patch acceptance. The number of OpenAI-generated patches merged, rejected, or rewritten is more important than the number generated.
- kernelCTF results. Acceptance of the 21 LPEs would turn a conditional bounty estimate into a verified outcome.
- Independent reproduction. A third-party lab running the same pipeline on a known kernel would test the cost and hit-rate claims.
- Model disclosure. The “upcoming cyber model” is unnamed. Its release, access controls, and safety policy will shape how quickly the capability spreads.
- Technical report on the novel techniques. Once the vulnerabilities are patched and disclosed, the 10 techniques can be reviewed rather than taken on trust.
Bottom line
OpenAI alleges a step change in autonomous vulnerability research: not a demo that finds a few bugs, but a pipeline that reproduces, exploits, and patches hundreds of Linux LPEs in one run. The methodology is detailed enough to take seriously. The 948 number is not yet an independently verified fact. The right response is to plan for cheap, continuous exploit discovery while demanding the public evidence that would make the claim checkable.