OpenAI's AI found 948 Linux root exploits: how it worked

On 4 November 2026, OpenAI reported that a pipeline of AI agents found 948 distinct ways to become root on a recent Linux kernel. Each one is a local privilege escalation: a bug that lets an ordinary user on a machine take full control of it. By OpenAI's own count, the whole run cost $1,213,430 in API credits.

The number is large, but the pipeline is the real story. Software has found kernel bugs for years. Turning a bug into a working exploit has mostly needed skilled humans. This run automated both steps, at roughly $1,280 per distinct exploit.

A note on sources: every figure below is OpenAI's own, from its post "A thousand fewer paths to root" as reported in several detailed write-ups that agree with each other. They are listed at the end. No outside group has reproduced the results yet.

What is a Linux privilege escalation exploit?

A local privilege escalation (LPE) exploit is code that starts as a normal user and ends as root, the account that controls everything. "Local" means the attacker can already run code on the machine, for example through a weak web app, a shared server or a malicious app. An LPE bug alone does not let someone break in over the internet.

The Linux kernel is a prime target because it runs with the highest privilege on servers, cloud machines and Android phones. A memory bug in kernel code, such as using memory after it has been freed, can sometimes be bent into control of the whole system. Modern kernels add defences that make this much harder:

• KASLR: loads the kernel at a random address at boot, so an exploit cannot know where things are.
• SMEP: stops the kernel from running code that sits in user memory.
• SMAP: stops the kernel from touching user memory unless it means to.

OpenAI says its test machines ran with these defences turned on. A working exploit had to get past them, not just crash the kernel.

How did OpenAI's pipeline find 948 root exploits?

OpenAI's pipeline was a funnel of agent stages. Each stage passed fewer, better leads to the next one:

1. 1Scout: agents picked 5,034 audit targets, covering about 2.8 million lines of code, roughly 7% of the kernel.
2. 2Analyst: agents read that code and wrote up 2,308 candidate bugs in about 12 hours.
3. 3Validation: agents tried to trigger each bug inside an isolated virtual machine running KASAN, a kernel tool that catches memory errors. 1,724 bugs reproduced, about 75%.
4. 4Screening: agents sorted the real bugs by what they could lead to. 1,238 looked like privilege escalation and 313 like information leaks.
5. 5Exploit writing: agents wrote 1,169 working root exploits and 291 information-leak proofs. Success meant "a root shell was obtained".
6. 6Variant analysis: many exploits shared a cause. Counting one per distinct patch needed to fix it left 948.

Most of the money went to the later stages. Analysis cost $316,549, validation $73,330 and exploit writing $775,929. Exploit writing alone was about 64% of the total. OpenAI calls its cost figures an upper bound.

One early failure shaped the design. In a trial run, 20 of 200 "successful" exploits reached root through a different bug from the one they were given, often another unknown flaw. The fix was stricter task rules plus an independent check that each exploit really used its own bug.

This is a lesson for anyone who builds agents. A success signal like "got root" can be met in ways you did not intend. If agents are new to you, start with our explainer on what AI agents are.

Which AI model did OpenAI use?

The write-ups we checked do not name the model. They describe it as a newer, unreleased cyber model. OpenAI's earlier runs show how fast this moved in 2026. A June run with GPT-5.5 Cyber produced 24 privilege-escalation exploits. A July run with GPT-5.6 Sol produced 166, for $513,690. The latest run produced 948 distinct ones.

Treat those three runs as rough markers, not a clean trend. The model, the kernel snapshot and the test setup all changed between them.

How is this different from kernel fuzzing?

Fuzzing tools such as Google's syzkaller have found kernel bugs for years. They feed random system calls to the kernel and watch for crashes. A crash is only a lead. Deciding whether it can become root, and then writing the exploit, has needed expert time.

OpenAI's agents worked differently. They read source code to find bugs, proved each bug in a virtual machine, and then did the exploit work too. The two approaches can support each other: fuzzers find crashes cheaply, and agents could help sort out which crashes matter.

How were the bugs reported and fixed?

OpenAI says it followed guidance from the kernel community. It reported critical bugs first and is sending the rest in batches through partners in its Patch the Planet programme. Ten days after the scan, 61 fixes had been merged upstream, 43 were staged for merging and 299 were under public discussion.

So most of the 948 were still being worked on when OpenAI published. That points to the main worry about runs like this. Each report needs a maintainer to read it, check it and write or review a patch, and maintainer time is limited. A machine that finds bugs faster than people can fix them moves work onto those people. One developer's write-up called this an "open-source tax".

What does the 948 number prove, and what does it not?

The run shows that AI agents can now do the full chain, from reading code to a working exploit that gets past standard defences, at scale and at a known price. It does not show some things people may read into it:

• Not remote attacks: every exploit needs the attacker to already run code on the machine.
• Not 948 fixed bugs: most were still being fixed when OpenAI published.
• Not a fixed price: the cost depends on the model, the kernel snapshot and the test setup.
• Not the whole kernel: only about 7% of the code was scanned.
• Not independent: the numbers are OpenAI's own and have not been reproduced.

Our view: the 7% figure is the one to remember. If a scan of 7% of the kernel produced 948 distinct root exploits, defenders should expect similar tools in attackers' hands, and should plan for faster patching. The write-ups also report that OpenAI held back ten exploitation techniques for safety reasons. The dual-use problem is no longer theoretical.

For readers who run Linux: keep your kernel updated. Fixes from this run will arrive as normal kernel updates over the coming months.

Research ideas for students

You do not need $1.2 million to study these questions. Here are projects that stay safe and legal:

• Crash triage: take public crash reports from syzbot, Google's automated kernel fuzzer, and test whether an open model can tell which ones are real security bugs. Check its answers against the fixes merged later.
• Patch quality: compare AI-written kernel patches with the versions maintainers finally merged. What did the humans change, and why?
• Reward hacking: build a toy task where an agent must use one specific bug, and measure how often it finds another way to "succeed".
• Deduplication: many exploits shared a root cause. Design a method that groups bug reports by cause, and test it on public CVE data.
• Maintainer load: measure how long kernel security patches take to merge, before and after AI-found reports became common.

Only test on machines and virtual machines you own. Never test systems that are not yours, and report real bugs through the project's security contact. If you want to practise kernel security legally, Google's kernelCTF programme pays for exploits against its own test kernels.

For the other side of AI security, where the AI system is the target, see our guide to the OWASP Top 10 for LLM applications and our post on AI guardrails.