Did an AI pipeline find 948 Linux paths to root? OpenAI reports exploits, patches and a validation warning
OpenAI says a controlled scan produced 1,169 working local-privilege-escalation exploits and 948 distinct candidate patches at a $1.21 million API cost. The company report is detailed, but upstream acceptance and independent reproduction remain incomplete.
The short version
- What happened
- OpenAI reports scanning 5,034 targets covering about 2.8 million Linux-kernel lines, producing 2,308 deduplicated candidates and dynamically reproducing 1,724.
- Who it affects
- Linux users benefit only when validated fixes reach maintained distributions and are installed.
- What remains unproven
- First-party company report using an unreleased cyber model.
Keep in mind
First-party company report using an unreleased cyber model.
No complete public mapping of all 948 patches to accepted upstream fixes.
Controlled virtual machines do not represent every Linux configuration.
Bounty valuations are hypothetical and not realised revenue.
Source analysis · 1 linked source. Primary analysed source date: 4 November 2026.
Keep following the evidence
Join The Impact Brief founding list for selected AI reports, their effect on people and the evidence limits. Read a sample first.
Read the full report · 7 min The evidence, methods, implications and limitations
The finding: one pipeline moved from code review to working root exploits
OpenAI reports that an autonomous security-research pipeline scanned part of the Linux kernel, reproduced 1,724 vulnerabilities and produced 1,169 working local-privilege-escalation exploits in isolated virtual machines. Variant analysis then generated 948 distinct candidate patches, which the company uses as its count of unique LPE vulnerabilities. A successful exploit obtained a root shell from an unprivileged local account on a stock desktop operating system with standard protections enabled. The end-to-end mid-October run cost $1,213,430 in API credits.
The scale is consequential because the Linux kernel underpins servers, Android devices, cloud infrastructure and other critical systems. It is also easy to misstate. The publication does not say that 948 previously unknown flaws are all still exploitable in current Linux, or that every proposed patch has been accepted upstream. During the ten-day run and manual analysis, 61 were already patched, 43 had staging patches and 299 were under public discussion. OpenAI says it has sent hundreds of reports and patches and is working through the rest with maintainers and partners.[1]
Five stages narrowed 2,308 candidates into reproducible evidence
Scout agents first identified 5,034 audit targets covering about 2.8 million lines, roughly 7% of the kernel, chosen for reachability by low-privileged users and security relevance. Analyst agents reviewed those targets and produced 2,308 deduplicated candidate findings within 12 hours. Triage agents then attempted to trigger each candidate in a virtual machine using Kernel Address Sanitizer, observing both program output and the system console. Within 30 hours they reproduced 1,724, or 74.7% of the candidates.
OpenAI reports that most unreproduced cases required elevated privileges, difficult race conditions or trigger conditions that exceeded the time budget; 3.1% were classified as incorrect model analysis. Dynamic reproduction is stronger evidence than a static warning, but it is not yet the same as an exploit that crosses a security boundary. An initial screening step therefore narrowed the reproduced set to 313 information-leak and 1,238 LPE candidates for exploit development. That explicit funnel is one of the report's most useful features because it keeps candidate, reproduced and exploitable counts separate.[1]
The distinction that matters
How the 948 figure was reached
The stages use different denominators; candidates, reproduced bugs, working exploits and distinct patches are not interchangeable.
2,308
Deduplicated static candidates
From 5,034 targets
1,724
Dynamically reproduced
KASAN evidence in isolated VMs
1,169
Working LPE exploits
Root from an unprivileged account
948
Distinct candidate patches
Used as unique LPE count
Standard mitigations were enabled, and unique flaws were counted by patches
Exploit-development agents ran against virtual machines configured with protections used by a standard Linux distribution: SMEP, SMAP, KASLR and HARDENED_USERCOPY. They produced 291 information-leak proofs of concept and 1,169 working LPE exploits. Because several exploits can reflect variants of one underlying flaw, OpenAI grouped them through variant analysis and generated 948 distinct patches. That patch count, not the raw exploit count, is the basis for the headline number of unique LPEs.
The report also describes a separate adapted kernelCTF run. On a hardened configuration with reduced attack surface—except that an incompatible SLAB_VIRTUAL mitigation was dropped—the pipeline found 25 information leaks and 21 LPE exploits in 112 hours for about $32,936. OpenAI compares this with 26 confirmed zero-day LPE exploits accepted by kernelCTF in 2026, but the new 21 are described hypothetically: the publication says what the bounty would be if accepted. That comparison should not be converted into 21 verified awards or confirmed upstream zero-days.[1]
A wrong-zero-day episode shows why a root shell is not enough
An early run appeared to produce 200 successful LPE exploits because each opened a root shell. Human review found that 20 had exploited a different zero-day from the vulnerability assigned to the agent. OpenAI tightened the constraints and added an independent check that the final exploit used its designated flaw. This is a vital negative result: outcome-only grading can reward an agent for taking an unintended path, precisely the problem security testing is supposed to diagnose.
Human researchers still review the root-cause analysis, minimal crashing proof of concept, patch, severity and full exploit before reporting. Patch quality also required iteration. Early patches could stop the proof of concept while adding excess code, creating performance trade-offs, breaking conventions or missing variants. Additional instructions and adversarial review improved the candidates, but OpenAI calls reliable automated patching an active research area. A generated patch should therefore be treated as evidence and a proposal, not as a safe update ready for automatic merge.[1]
The economics are measured, but the valuation is hypothetical
The API bill was itemised: $3,426 for scouting, $316,549 for analysis, $73,330 for validation, $44,194 for initial exploitability screening and $775,929 for exploitation, including both information leaks and LPE work. Successful LPE development averaged about $359 in credits, while processing an unsuccessful case cost more because difficult race conditions consumed time. OpenAI presents the overall $1.21 million as an upper bound that harness improvements could reduce, not as a price every defender could reproduce.
The company applies historical $20,000 and $70,000 competition bounties to 948 exploits to calculate a hypothetical value of $18.9 million to $66.3 million. That is not revenue, a market price or an accepted bounty total. It assumes each exploit would qualify independently at those rates. The economic comparison is useful for showing why well-resourced attackers and defenders might automate vulnerability research, but it should not outrun verification, disclosure capacity or maintainer time. Finding more reports can also create a triage burden for open-source projects.[1]
What defenders should conclude—and what would change the assessment
The immediate lesson is defensive: keep kernels patched, restrict low-privileged access, isolate workloads and assume local access on an outdated system may be more dangerous as exploit development becomes cheaper. Software projects need reproducible reports, deduplication against current code, coordinated disclosure and patch review. Organisations using autonomous research should sandbox targets, verify the exploit path, monitor tool use and separate discovery from deployment authority. The report offers no reason to publish exploit details or automate production patching without maintainers.
Confidence in the scale claim would rise with a public accounting of accepted upstream patches, CVEs or advisory links after coordinated disclosure; independent reproduction; model and harness documentation sufficient for comparison; and results on other mature codebases. It would weaken if many patches duplicate known reports, fail maintainer review or cannot be reproduced outside OpenAI's environment. This is a detailed first-party company publication, not a peer-reviewed paper, and its unpublished upcoming model is commercially relevant. It is significant current research, but not evidence of active mass exploitation, so it remains Latest rather than Breaking.[1]
Continue the story
Read next
Continue exploring cybersecurity: compare the finding and its evidence limits.
An internal Claude model built five exploit chains; the disclosed flaws were patched before publication
Anthropic says its red team used an unreleased model to combine vulnerabilities across Chrome, Safari, Android, Windows and Linux. Vendor advisories confirm shipped fixes, but the programme was company-run and does not measure how often other models or attackers can repeat the work.
Read the next reportExplore the full source and evidence record
What this means for people
- Linux users benefit only when validated fixes reach maintained distributions and are installed.
- Maintainers face a larger triage and disclosure workload alongside potentially faster patch proposals.
- Security teams need path validation so an agent does not prove the wrong vulnerability.
Global context
AI-assisted vulnerability research is moving from individual code suggestions to scaled discovery, exploitation and patch proposals. The bottleneck shifts toward validation, coordinated disclosure and maintainer review. The same capability can help defenders and lower attacker costs, making access control and patch velocity central public-interest questions.
What the evidence does not yet show
- First-party company report using an unreleased cyber model.
- No complete public mapping of all 948 patches to accepted upstream fixes.
- Controlled virtual machines do not represent every Linux configuration.
- Bounty valuations are hypothetical and not realised revenue.
What to watch next
- Accepted Linux patches and advisories.
- Independent reproduction.
- Maintainer workload and duplicate-report rates.
- Whether patch quality survives variant and regression testing.
Living evidence record
Impact record IAI-08EASUM
Evidence stage
Observed
Confidence
Supported
Reporting basis
Source analysis
Independent or research support
Not yet
Record status
Monitoring
Last checked
5 November 2026
Source trail
1 direct source across 1 source type.
People impact
Documented in this record.
Uncertainty
Limits and next checks are explicit.
Stages describe the evidence available—not whether a technology is good or bad. See the public method.
Single-source reporting disclosure
This record analyses one direct source. It can establish what OpenAI published or reported, but it is not independent corroboration of every performance claim or predicted outcome. The confidence label will change only when broader evidence is added.
Evidence trail
Sources used for this report
Links checked 5 November 2026
Research question, topics and regions
How OpenAI's autonomous vulnerability-research pipeline discovered, reproduced, exploited and proposed patches for Linux-kernel flaws, and which claims have not yet been independently verified
Topics: Linux · Cybersecurity · Vulnerability research · AI agents · Open source
Regions: United States · Global
This report is labelled source analysis. We summarise and analyse source material in our own words; company statements remain attributed claims until independently supported. Translated summaries preserve the meaning of the original source and link back to it. Read our editorial standards.
Reader commentary
What does this mean where you are?
Tell us what you have seen at work, in your community or in everyday life. A question is welcome too. No account is needed; we review notes before publishing them.
Explore commentary across the portal →Published reader notes
0No published reader notes yet. You can start the evidence-led discussion above.
Prefer a private correction or response? Contact the newsroom.