OpenAI says it has built an autonomous pipeline that can find Linux kernel bugs, prove they are exploitable and draft the fix. In a November 4, 2026 research post, the company reports that one October run reproduced 1,724 vulnerabilities and produced 948 working local privilege escalation (LPE) exploits. The run cost $1,213,430 in API credits. Each exploit gives an unprivileged local user root access.
This is OpenAI's own report, based on an upcoming cyber model it has not released. Treat the numbers as claims from the lab, with the method described in detail and the exploit code withheld. Below we walk through the pipeline, the cost table, the failures OpenAI admits, and what defenders can do now.
TL;DR: the numbers OpenAI published
| Question | Answer |
|---|---|
| What was scanned? | The latest Linux kernel master branch, mid-October 2026, with test VMs running a stock desktop OS |
| How many candidate findings? | 2,308 after deduplication |
| How many reproduced? | 1,724 (about 74.7 percent of candidates) |
| How many root exploits? | 948 distinct LPE exploits, plus 291 information-leak proofs of concept |
| What did it cost? | $1,213,430 in API credits, about $1,279 per LPE exploit |
| Which model? | An "upcoming cyber model", unnamed and unreleased |
| Was a human involved? | Yes, researchers reviewed exploits, patches and severity before reporting to maintainers |
| Were exploit details published? | No. The 10 novel techniques are described only at category level |
Agents that act on your behalf need rules. See how explainx helps secure your agents →
How the five-stage pipeline works
OpenAI describes the system as five stages, each run by agents.
- Discovery. Scout agents read the kernel tree and pick audit targets that are reachable by a low-privileged user and security relevant. They selected 5,034 targets, about 2.8 million lines of code, roughly 7 percent of the kernel. Analyst agents then scanned those targets with a workflow similar to the Codex Security plugin and produced 2,308 candidate findings in 12 hours.
- Dynamic validation. A triage agent wrote a proof of concept for each candidate and ran it in an isolated virtual machine with the Kernel Address Sanitizer (KASAN) enabled. It iterated until it reproduced the bug or ran out of ideas. In 30 hours it reproduced 1,724 of them.
- Exploitability assessment. A deliberately permissive screening agent narrowed the set to 313 information-leak candidates and 1,238 LPE candidates. Exploit-development agents then worked in VMs with standard protections on, including SMEP, SMAP, KASLR and HARDENED_USERCOPY. The agents produced 291 leak proofs of concept and 1,169 working LPE exploits.
- Patch generation. Variant analysis collapsed those 1,169 exploits to 948 distinct vulnerabilities, each with a candidate patch.
- Human review. Security researchers checked each bundle, which includes a root-cause analysis, a minimal crashing proof of concept, a patch and a full exploit, before anything went to maintainers.
The design choice worth noting is where the effort went. OpenAI says the hard part was no longer discovery. It was working out which findings could be reproduced, what security boundary they crossed, and which deserved maintainers' attention first.
Where the $1.2 million went
OpenAI breaks the cost down by stage. The table uses the figures in the post.
| Stage | API cost |
|---|---|
| Scout agents (audit targets) | $3,426 |
| Analyst agents (candidate findings) | $316,549 |
| Validation (reproduction) | $73,330 |
| Screening agent | $44,194 |
| Exploitation, total | $775,929 |
| Of which information leaks | $84,929 |
| Of which LPE candidates | $691,000 |
| Whole run | $1,213,430 |
Two details stand out. First, exploitation is the biggest line. Processing an LPE candidate averaged $558, about twice the $271 for an information-leak candidate, because root exploits need strategy planning, object selection and mitigation bypasses. Second, failures are expensive. Unsuccessful exploitation attempts cost $3,922 per case (69 cases), against $360 for each of 1,169 successes. OpenAI says a give-up rule, such as stopping after an hour with no progress, would have cut the bill.
The company also stresses that it was measuring capability, not optimizing cost, so the totals are "more an upper bound".
The bounty comparison, and how to read it
OpenAI compares its cost with public bug-bounty prices. Pwn2Own and TyphoonPWN have historically paid $20,000 and $70,000 for Linux kernel LPE exploits. Applied to 948 exploits, that gives a hypothetical value of $18.9 million to $66.3 million, or 16 to 55 times the pipeline's cost.
A second test used an adapted version of Google's kernelCTF environment, a hardened kernel with reduced attack surface. The pipeline got 25 information-leak proofs of concept and 21 LPE exploits in 112 hours for about $32,936. OpenAI notes that 26 confirmed 0-day LPEs were accepted by kernelCTF in 2026 at the time of writing. If all 21 had been accepted, the bounty would be around $1.5 million, about 45 times the scanning cost.
Read this carefully. The dollar values are hypothetical. Bounty programs would not pay for 948 exploits, many are likely duplicates or low-value variants, and the prices are historical. The honest takeaway is narrower: OpenAI says that on public payout amounts the research was "net profitable", which is the economic argument for defenders to scan first.
What went wrong, in OpenAI's words
The post is more candid about errors than most vendor reports, and these are the parts we would read twice.
- The wrong 0-day. In an early run the exploitation stage reported 200 successful LPEs. Human review found 20 of them reached root through a different 0-day than the assigned one. OpenAI added an independent check that each exploit used its assigned bug. Its lesson: verify the path to a result, not only the result.
- A bug in the test rig. In the kernelCTF run, an analyst agent triggered a crash, traced it to a QEMU TCG flaw without having QEMU's source, and an exploit-development agent then built a privilege escalation for it. The flaw was already fixed upstream but not in the build OpenAI used. The company recommends testing infrastructure before offensive research, and says it has disclosed and patched issues in Kata, Moby/Docker and gVisor.
- Patch quality. Early patches were correct for the proof of concept but sometimes added unneeded code, broke coding conventions or missed variants. More instructions and iteration helped. OpenAI also suggests using models for adversarial review of both human and AI patches.
- Race conditions. Most unreproduced candidates needed elevated privileges or hit hard-to-trigger conditions. Only 3.1 percent were wrong analysis, where the model assumed an impossible condition.
Stronger models, lighter harnesses
Two findings matter for anyone building agent systems.
Newer models find much more. A late-July run on GPT-5.6 Sol found and exploited 166 unique LPEs for $513,690. The October run with the upcoming cyber model found 948 for $1,213,430, despite three months of kernel hardening in between. That is more than five times as many novel LPEs for about 2.4 times the spend.
Scaffolding can go stale. With GPT-5.5 Cyber, OpenAI supplied 103 exploitation techniques in a model-friendly format. Across 63 exploitation candidates this lifted the success rate from 76.2 percent to 88.9 percent. With GPT-5.6 Cyber the model chose and applied techniques itself. A lightly orchestrated GPT-5.6 workflow beat the heavily scaffolded GPT-5.5 one, and adding the technique layer back gained only 1.5 points. The lesson for builders: re-test your harness whenever the base model changes. For another Daybreak result, see Cloudflare's AI vulnerability fixes and its $1,100 Codex rebuild.
OpenAI also says the agents used at least 10 exploitation techniques that were new to third-party kernel experts: two persistent elastic objects for heap spraying, two page-grooming techniques, five data-only privilege escalation techniques and one arbitrary type confusion. It does not publish the details.
What Linux maintainers did meanwhile
The scan ran for 10 days. During that time, 61 LPEs were patched upstream, 43 had staging patches, and 299 were being reported and discussed publicly. Elsewhere in the post OpenAI puts the early-window figure as over 100 patched or staged, with about 300 more under public discussion.
That overlap has a practical effect. Automated reports go stale fast, so OpenAI advises re-validating findings against the latest code before sending them. It says it followed the kernel community's guidance, started with critical bugs, and has sent hundreds of reports and patches so far. The remainder will go out gradually with partners in its Patch the Planet effort, part of the wider Daybreak security programme.
How this fits the recent run of AI security news
This is the largest published single-run number so far in a month crowded with AI cyber claims.
- In June, OpenAI said GPT-5.5 Cyber found Linux kernel bugs and built 24 LPE exploits. The new post is the expansion of that work.
- Anthropic's deputy CISO warned that things will get "a lot worse" for 18 months, which we covered in what is confirmed and what to do.
- Trail of Bits released tools after 21 regressions in 130 AI-assisted patches: patching-bugs and regression-hunt.
- OpenAI also quadrupled its payouts in the $30,000 critical bug bounty, a useful benchmark for the cost numbers above.
- The original programme launch is in our Daybreak and Codex Security explainer.
What defenders should do now
OpenAI's own recommendations, plus the practical steps that follow from them:
- Patch the kernel promptly. The post says a low-privileged account on an out-of-date system should be treated as equal to root for a well-resourced attacker. Shared hosts, CI runners, build servers and developer containers are the exposed cases.
- Limit blast radius. Run untrusted code in Firecracker microVMs or gVisor, not plain containers on a shared kernel.
- Rescan as models improve. Code audited three months ago is not clean against a newer model. OpenAI says large projects need multiple rounds to "bottom out" latent bugs.
- Use AI for patch review. Ask a model to attack your fix for bypasses and missed variants before merging.
- Verify agent results end to end. If you run autonomous security agents, add independent checks that a claimed exploit used the intended path, and keep the agents isolated.
- Control your own coding agents. If agents run on machines with privileged access, enforce policy at action time. AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.
The longer view in OpenAI's conclusion is that, within a few years, frontier models will likely find any vulnerabilities that exist in a given project, and even weaker models may be able to exploit them once disclosed. It points to secure-by-default code, smaller attack surface and formal verification as the durable answers.
What is confirmed and what is not
Confirmed by the source. The pipeline stages, the counts, the cost table, the patch status counts, and the admitted errors are all in OpenAI's post, published on November 4, 2026 under its security section.
Not independently verified. We did not find a third-party audit of the 948 figure, a named list of CVEs, or the model's identity. The exploit code and the 10 new techniques are not public, so outsiders cannot reproduce the result. The bounty valuation is a hypothetical built by OpenAI. Kernel maintainers' own reports, as they land, are the best check.
What would change our read. Public CVE identifiers and upstream commits tied to the October run would turn the headline into something checkable. A published name and system card for the cyber model would show who can run the same process, and at what price.
Why this matters beyond Linux
The cost per exploit is the number to remember. At roughly $1,279 per root exploit in a first-generation pipeline that OpenAI calls an upper bound, offensive and defensive kernel research both get cheaper than the bounty prices that used to define the market. That pushes toward faster patch cycles, more automated triage on the maintainer side, and tighter isolation for anything that runs untrusted code. It also raises the stakes for open-weight models with similar skills, which we covered in Anthropic's GLM-5.3 cyber evaluation.
For learners, the transferable lesson is about agent design: split a hard task into stages, verify each stage with tools (KASAN crashes, root shells), keep a human gate before anything leaves the building, and re-check the scaffolding each time the model improves.
Figures and quotes in this post are accurate as of November 4, 2026, from OpenAI's published write-up. Check the primary source for updates.