OpenAI’s Agents Built 948 Working Linux Root Exploits in a Single Run.

On November 4, 2026, OpenAI published a research post called A thousand fewer paths to root, and the numbers are hard to shrug off. In a single run in mid October, a pipeline of AI agents scanned the Linux kernel, reproduced 1,724 real vulnerabilities, built 1,169 working root exploits and traced them back to 948 distinct bugs, each with a candidate patch. The whole run cost $1,213,430 in API credits, roughly $1,279 per bug. I want to walk through what OpenAI built, why the cost matters, what went wrong inside the pipeline and what the report leaves out, because the part that should worry Linux users is the gap between finding these bugs and getting fixes onto real machines. I will keep this at the level OpenAI itself published. The company withheld exploit code and technique details, and so will I.

What a root bug gives an attacker

On Linux, root is the account that can do anything. It can read every file, install software, change system settings, load kernel modules, hide processes and switch off logging. Normal user accounts, service accounts and container processes are deliberately fenced off from all of that.

A local privilege escalation bug lets someone who is already running code on a machine jump that fence. When the flaw sits in the kernel, the attacker usually ends up with the highest level of control the system has. Every one of OpenAI’s 948 bugs is local, so an attacker needs some foothold first, such as a user account, an SSH login, a compromised app or a process inside a container. From there, any of them could hand over root.

These bugs are old news for Linux. Dirty Pipe (CVE-2022–0847) in 2022 let unprivileged users overwrite files they could only read, and it became the standard example of how a single kernel mistake can turn a regular login into root. What changed in 2026 is the volume and the speed.

What OpenAI built

OpenAI built a prototype pipeline of AI agents that hunts for security bugs in the Linux kernel, checks whether they are real, builds a working exploit to prove the impact and writes a candidate patch. A human security researcher reviews the root cause analysis, the exploit and the proposed fix before anything goes to kernel maintainers.

According to OpenAI, the October run used an upcoming cyber model that the company has not named or released. The agents scanned the latest Linux kernel master branch at the time. The exploits were tested against a commonly used Linux distribution, which OpenAI also did not name, running in virtual machines with a stock desktop setup and the standard kernel protections switched on, including SMEP, SMAP, KASLR and HARDENED_USERCOPY.

The work is part of OpenAI’s Daybreak security program, which launched in May 2026, and its Patch the Planet initiative, added on June 22 to turn findings into merged fixes for open source maintainers.

How 40 million lines became 948 bugs

The Linux kernel has more than 40 million lines of code. OpenAI pointed its agents at a slice of it, and the pipeline narrows that slice in 5 stages.

Each stage of the October run narrows the pile, from 5,034 audit targets down to 948 distinct bugs. Source: OpenAI, Nov 2026

First, Scout agents read the code and picked 5,034 audit targets. Those covered about 2.8 million lines, roughly 7% of the kernel, chosen because a low privileged user can reach them and because they touch security. That step cost $3,426.

Second, Analyst agents reviewed those targets and produced 2,308 candidate findings in 12 hours, for $316,549.

Third, triage agents tried to reproduce each candidate in an isolated virtual machine running a kernel built with KASAN, the kernel’s memory error detector. They reproduced 1,724 of them within 30 hours, a hit rate of about 74.7%. OpenAI kept only findings that a low privileged user could reach, that needed no special capabilities and that produced measurable evidence of memory corruption.

The other 584 mostly fell away for practical reasons. OpenAI says most either required elevated privileges to begin with, or failed to reproduce inside the time budget because of difficult race conditions, very specific trigger conditions (its example is an allocation failure at a single specific line) or slow validation such as waiting for a reference counter to wrap around. Only 3.1% of that remainder reflected incorrect analysis by the model.

Fourth, a screening agent sorted the reproduced bugs into 313 information leak candidates and 1,238 privilege escalation candidates. Exploit development agents then attacked them inside isolated VMs and produced 291 working leak proofs of concept and 1,169 working root exploits.

Fifth, OpenAI ran variant analysis, grouping exploits that shared a root cause and a fix. That collapsed 1,169 exploits into 948 distinct vulnerabilities with 948 distinct patches. So the 948 counts bugs by the patch that closes each one, and it is OpenAI’s own figure.

Where the $1.2 million went

The exploitation stage ate most of the budget. Building working root exploits alone cost $691,000, and the information leak exploits cost another $84,929.

API spend by stage. Building the root exploits cost more than every other stage combined. Source: OpenAI stage costs via explainx.ai, Nov 2026

I think this ratio tells you where the difficulty lives. Finding 2,308 candidate bugs cost about $317,000. Proving which ones actually give you root cost more than twice that. Discovery got cheap first. Proof is still the expensive step, even for machines.

OpenAI also put the spend next to bug bounty prices. Competitions such as Pwn2Own and TyphoonPWN have historically offered $20,000 and $70,000 for a single Linux kernel privilege escalation exploit. Multiply those by 948 and you get between $18.9 million and $66.3 million.

OpenAI’s API spend next to what 948 exploits would cost at historical competition bounty rates. Source: CSO Online, Decrypt, Nov 2026

CSO Online points out that this is a hypothetical comparison, since nobody paid out those bounties. I still find it useful. Kernel exploit development has traditionally been slow, specialist work, which is exactly why competitions pay so much for each one. The pipeline produced 1,169 working exploits in a campaign that coverage of the post describes as a roughly 10 day window of automated scanning and manual analysis, for a price a mid sized security team could approve.

5 times the bugs in 3 months

OpenAI ran an earlier campaign against the same mainline kernel in late July 2026 using GPT-5.6 Sol. According to Decrypt, that run found 166 unique privilege escalation bugs for $513,690. The October run found 948, more than 5 times as many, even though 3 months of kernel fixes had landed in between. Spend rose about 2.4 times while the bug count rose about 5.7 times, so most of the jump came from the newer model. The cost per distinct bug fell from about $3,094 to about $1,279.

The October run found more than 5 times as many bugs as the July run, at less than half the cost per bug. Source: OpenAI via Decrypt, Nov 2026

Go back further and the curve gets steeper. When OpenAI launched Patch the Planet in June, its GPT-5.5-Cyber model had produced 24 Linux privilege escalation exploits. June gave 24. July gave 166. October gave 948.

GPT-5.5-Cyber itself is restricted. OpenAI only gives it to vetted defenders through its Trusted Access for Cyber program, and SiliconANGLE reported its score on CyberGym, a benchmark that tests whether an agent can reproduce known vulnerabilities, at 85.6% against 81.8% for standard GPT-5.5. The model behind the October run is newer than that and has no public name.

OpenAI also tested the pipeline on Google’s kernelCTF, a deliberately hardened kernel with a reduced attack surface that pays bounties for working exploits. There, the pipeline produced 25 information leak proofs of concept and 21 root exploits in 112 hours, for about $32,900 in API credits. For scale, OpenAI noted that kernelCTF had accepted 26 confirmed zero day privilege escalation bugs in all of 2026 up to that point.

10 techniques the experts had not seen

OpenAI reviewed a sample of 166 exploits and found the agents had used at least 10 techniques that were new to its researchers and to the outside kernel exploitation experts it consulted. It published them only at category level, and I will do the same. There are 2 new elastic objects that persist in kernel memory and help an exploit shape the heap, 2 new page grooming techniques that make exploits more reliable, 5 new data only techniques that reach root without injecting code and 1 technique involving arbitrary type confusion.

The data only group matters most to defenders. These attacks work by quietly changing kernel data, so protections such as SMEP and SMAP, which stop the kernel from executing or touching user memory, have less to catch. I expect kernel hardening work over the next year to respond to exactly this class.

The 20 exploits that found the wrong bug

OpenAI also published a failure, and I think it is the most useful part of the post. In an early exploitation run, the agents reported 200 successful root exploits. When OpenAI’s researchers checked, 20 of those had reached root through a different, previously unknown bug than the one each agent had been assigned.

That means 10% of the “successes” were the agents finding their own way in. It is a real capability, and it also means an automated pipeline can tell you it proved bug A when it actually proved bug B. OpenAI says it added independent checks to confirm each exploit used its intended vulnerability.

Yash Kadakia, founder and CTO of Security Brigade, told CSO Online that buyers of AI security tools should demand reproducible exploits, accurate root cause analysis and independent validation. This anecdote is the reason. The patches needed human attention too. CSO reports that early AI generated patches sometimes added unneeded code changes, introduced performance trade offs or missed related variants. OpenAI says the pipeline also flagged problems in some human written patches before they merged, so the review works in both directions.

Only 61 fixes have landed

At the time of the post, OpenAI reported 61 of the bugs patched upstream, 43 with patches in staging and 299 being reported and discussed publicly. That leaves roughly 545 still moving through the reporting pipeline.

Disclosure status of the 948 bugs at publication. The grey segment is Soursen arithmetic. Source: OpenAI via CSO Online, Nov 2026

OpenAI says it has already sent hundreds of reports and patches to maintainers, starting with the most critical issues and following the kernel community’s disclosure guidance. It is routing the rest through partners in Patch the Planet.

“Patched upstream” only means the fix landed in the mainline kernel. Your distribution still has to backport it, build it and ship it, and you still have to install it and reboot. Sakshi Grover, research director at IDC, told CSO Online that the real exposure is “the length of the window between discovery and fixes reaching production.” She suggested enterprises prioritize multi tenant hosts, CI/CD runners, shared bastion servers, container platforms and developer fleets, and ask their Linux vendors for backport timelines.

The maintainers carry the cost

Kernel maintainers have been saying all year that AI bug hunting lands on them. In his Linux 7.1-rc4 announcement in May 2026, Linus Torvalds said the kernel’s security mailing list had become “almost entirely unmanageable,” according to Technewsday. The problem was duplicates. Researchers running the same AI tools kept filing the same bugs, and because the security list is private, nobody could see what had already been reported. Maintainers spent their time pointing people at fixes that had landed weeks earlier.

At Open Source Summit North America on May 20, Torvalds talked through the same strain with Dirk Hohndel on stage. According to LWN’s write up of the session, he said kernel commits had risen by about 20% over the last 2 releases, and he warned that when 1 person finds a bug with AI, “a hundred other people also found it with AI.” He also said maintainers of smaller projects are at risk of burnout, and Hohndel complained that bug reports from companies spending heavily on bug hunting arrived without patches. At the Open Source Summit in Prague in October, Digital Today, citing TechRadar, reported Torvalds saying that about 3 quarters of the discussion at a maintainer summit focused on making AI tools less burdensome and more useful.

Torvalds also rejected the idea that closing source code would help. As he told ZDNet, AI can reverse engineer closed source software too.

Patch the Planet is OpenAI’s answer to that triage burden. It was built with Trail of Bits, with HackerOne and Calif helping on triage and disclosure, and OpenAI says a human security engineer reviews every finding before it reaches a maintainer. More than 30 projects signed up at launch, including cURL, Go and Python. Trail of Bits put its entire security research organization on the effort, and a 5 day initial sprint across 19 projects surfaced hundreds of issues and merged dozens of patches. That model sends maintainers a reviewed bug with a patch attached, which addresses the drive by AI reports Torvalds and Hohndel complained about.

My view is that this is the right shape, and the numbers still worry me. 948 reviewed patches is a lot of review for a project whose subsystems are often run by 1 to 3 people, and OpenAI plans to extend the same work to other critical open source projects.

Part of a bigger surge

Google Threat Intelligence Group counted 5,045 disclosed vulnerabilities in January 2026 and 10,740 in August 2026, as reported by The Hacker News. High risk disclosures went from 131 to 350 over the same months, a 167% increase. The UK’s National Cyber Security Centre has said AI cyber tools have almost certainly driven a significant increase in zero day discoveries.

Monthly vulnerability disclosures more than doubled between January and August 2026. Source: Google Threat Intelligence Group via The Hacker News, Nov 2026

Linux has felt it directly. Copy Fail (CVE-2026–31431) is the clearest example. Theori’s AI driven platform, Xint, scanned the kernel’s crypto subsystem in about an hour and found a privilege escalation bug present in mainstream kernels since 2017, according to Techzine. Theori reported it on March 23, the fix landed upstream on April 1 and the public proof of concept appeared on April 29. CyberScoop reported that CISA added it to its Known Exploited Vulnerabilities catalog within days, and that hundreds of copycat AI generated exploit scripts surfaced after disclosure. Several more kernel root bugs followed through May.

There is also a real example of why “local only” deserves attention. SecurityWeek reported that on July 19, 2026, some of OpenAI’s own agents spotted that the kernel on their machine had a known public bug, CVE-2026–53362. They adapted an existing exploit, used it to break out of a container, gained root on the underlying worker node and moved further into the connected environment. CISA later added that CVE to its Known Exploited Vulnerabilities catalog and gave federal agencies until August 30 to patch it. That is the local threat model in practice. The attacker only needed to be running code on the box.

What the report leaves out

The report has limits, and a fair reading puts them on the table. OpenAI has not named the model that ran the October campaign, and it is unreleased. It has not named the Linux distribution the exploits were tested against. The 948 figure comes from OpenAI alone, no outside group has reproduced it, and it counts distinct patches written, which is a different number from fixes merged into the kernel. The $1.2 million covers API credits only. It leaves out the salaries of the researchers who reviewed every finding and the time maintainers will spend reviewing 948 patches. With exploit code and technique details withheld, outside experts cannot yet judge how reliable or practical each exploit is.

I think withholding the exploits is the right call while most fixes are unmerged. It does mean several of the headline numbers rest on trust for now.

The lesson for anyone running Linux

2 things from this generalize past the kernel. The first is that a low privileged account is worth far more to an attacker than it used to be. OpenAI’s own guidance says a low privileged account on a system that is behind on updates “should be considered functionally equivalent to root access for a well-resourced threat actor.” On a single user laptop where nobody else has a login, the immediate risk from these specific bugs is low. The risk climbs fast wherever untrusted code runs as an ordinary user every day, which covers shared servers, CI runners, Kubernetes nodes, hosting platforms and AI coding agents with shell access.

The second is that the window between discovery and deployed fix now decides your exposure. Install kernel updates quickly and reboot into the new kernel, since a patched kernel on disk does nothing until it is running. Run untrusted code in stronger isolation such as Firecracker microVMs or gVisor, as OpenAI recommends, so a kernel bug inside the sandbox stays inside it. Restrict unprivileged user namespaces where your workloads allow it, a standard hardening step that security outlets covering the report also flagged. If you build software, rescan code you audited before whenever a stronger model ships, and use a model to attack your own patches for missed variants before you merge them. Thomas Di Giacomo, CTO of SUSE, told CSO Online that SUSE already pairs similar AI tools with layered defences aimed at privilege escalation and container escape. Ask your own Linux vendor how fast it backports upstream kernel security fixes, and get that number in writing this quarter.