OpenAI uses AI agents to find 948 privilege escalation flaws in the Linux kernel

OpenAI published, in November 2026, the results of an autonomous pipeline that scanned the Linux kernel for local privilege escalation vulnerabilities (LPE). The report, released in the post "A thousand fewer paths to root," describes a scan carried out in mid-October 2026 that identified 2,308 vulnerability candidates, dynamically validated 1,724 of them, and produced 948 functional exploits capable of giving an unprivileged user full root access.

The work is a continuation of the Patch the Planet program, which in June 2026 had already shown the GPT-5.5 Cyber model finding kernel vulnerabilities and developing 24 proof-of-concept exploits. The difference now is scale: OpenAI turned that one-off experiment into a five-stage pipeline, running on a cybersecurity model not yet publicly released, and managed to multiply the result by almost 40 times.

How the pipeline works

The system is divided into five sequential stages, each with specialized agents:

• Discovery: "Scout" agents scan the code for relevant audit targets (accessible to unprivileged users), narrowing the scope before any deep analysis.
• Dynamic validation: triage agents generate a proof of concept for each candidate and try to reproduce it on an isolated VM running a kernel with KASAN (Kernel Address Sanitizer).
• Exploitability assessment: "ExploitDev" agents try to turn the validated vulnerability into a real exploit, on VMs with standard distribution protections (SMEP, SMAP, KASLR, HARDENED_USERCOPY) enabled.
• Patch generation: the pipeline itself proposes a fix, following the conventions of the surrounding code and static checking.
• Human review: OpenAI researchers validate the exploit, patch, and severity before reporting to the kernel maintainers.

The first stage audited about 2.8 million lines, just 7% of the kernel's total codebase (which exceeds 40 million lines), thanks to a reachability triage instead of scanning everything. This selection is what makes the cost viable: analyzing code irrelevant to an unprivileged attacker would be a waste of tokens.

The cost numbers that matter for budget planning

OpenAI published the cost of each stage in API credits, and the breakdown is the most useful part for anyone thinking about a security program with a real budget:

The average cost per successful exploit was US$ 359, but failed attempts cost an average of US$ 3,922 each (versus 1,169 successes at US$ 360): a sign that setting an abandonment criterion (OpenAI suggests stopping after one hour without progress) would avoid much of the waste.

Compared to bug bounty, the pipeline turned a profit

OpenAI also measured the result against real bug bounty program payouts. Using the historical amounts paid by Pwn2Own (US$ 20,000) and TyphoonPWN (US$ 70,000) per Linux LPE exploit, the 948 findings would be worth between US$ 18.9 million and US$ 66.3 million, 16 to 55 times the pipeline's total cost.

In a second test, run against Google's kernelCTF (which uses a hardened kernel with a reduced attack surface), the pipeline found 25 proofs of concept for information leaks and 21 LPE exploits in 112 hours, for US$ 32,936. For comparison, only 26 zero-day LPE exploits were accepted into kernelCTF throughout 2026 up to the report's publication. If the 21 exploits were accepted, the estimated reward would reach US$ 1.5 million, about 45 times the cost.

In short: with the model used in October 2026, finding and exploiting kernel vulnerabilities via AI agents is already economically viable both for defenders and, in theory, for attackers.

Linux maintainers reacted quickly, but that's also a warning

One data point stands out for anyone administering infrastructure: ten days after the October scan began, 61 of the LPEs found already had a patch applied upstream, 43 had a patch in staging, and 299 were already being discussed publicly. The kernel community's response speed is a positive sign, but it reinforces a concrete operational risk: anyone running an outdated kernel, a customized embedded fork, or a distribution without a fast patch cadence stays exposed for longer to the same class of flaw that OpenAI is uncovering in bulk.

The report also documents an interesting mistake worth noting as a lesson for anyone building a similar pipeline: in an initial run, 20 of 200 exploits reported as successful had actually achieved root by exploiting a different zero-day than the one the agent was supposed to be testing. The fix was to add an independent check confirming that the final exploit used exactly the attributed vulnerability: in other words, validating the result without validating the path to it is a trap in security automation too.

What changes for those running Linux in production

None of this is available as a finished product: the model used is described as "an upcoming cyber model," not yet released, and the pipeline is an internal research prototype. The closest artifact an engineering team can test today is the Codex Security plugin, cited in the report itself as the basis for the analyst agents' workflow, available in the openai/plugins repository on GitHub.

Even so, the practical implication for those maintaining servers, multi-tenant Kubernetes clusters, or products that depend on kernel isolation (containers sharing a host) is direct: the barrier to finding privilege escape vulnerabilities in Linux has dropped measurably, and that cuts both ways. Security teams can (and should) consider running automated reachability scans on the kernel actually used in production, especially on forks or older LTS versions that don't get the same researcher attention as the master branch.

It's also worth revisiting the finding about orchestration: OpenAI noted that, as the base model became more capable (from GPT-5.5 Cyber to GPT-5.6 Cyber), heavy scaffolding of exploitation techniques started adding little (just a 1.5 percentage-point gain). For those evaluating AI-based security tools, this suggests being wary of products sold with heavy prompt engineering on top of older models: the real gain tends to come from the model's capability, not from the orchestration layer around it.

What's still unresolved

The report is explicit about not having optimized for cost, only for methodology: the published figures are a ceiling, not a floor. There's also no full technical detail on the 10 new exploitation techniques the agents reportedly created (two object-spray, two page-grooming, five data-only, and one type-confusion), withheld for security reasons. That leaves the most practical question for technical readers unanswered: how replicable is this result outside OpenAI's controlled environment, using models available today via common APIs instead of the still-unreleased cyber model.