Vulnerabilities

OpenAI's AI pipeline wrote 948 Linux root exploits

By Yaali. November 6, 2026, 6 min read, Vulnerabilities, Patching, Threat intel.

An unreleased OpenAI model found and exploited 948 Linux kernel privilege escalation flaws in one run. What was tested, and how to shrink your kernel exposure.

On November 4, OpenAI published "A thousand fewer paths to root", a report on a prototype pipeline that hunts for Linux kernel bugs, proves them with working exploits and drafts the fixes. In one mid-October run, driven by an upcoming cyber model that OpenAI has not named, it produced 1,169 working local privilege escalation (LPE) exploits. An LPE takes an ordinary user account to root. After grouping exploits that hit the same underlying flaw, OpenAI counts 948 distinct vulnerabilities, at a total cost of $1,213,430 in API credits.

This affects anyone running Linux where people or code you do not fully trust get a shell: shared hosts, CI runners, container platforms, jump servers, developer laptops. OpenAI is not publishing the exploits and is withholding the new techniques. What changes is the economics. Pwn2Own and TyphoonPWN have historically paid $20,000 to $70,000 for one Linux kernel root exploit; this run spent an average of $1,279 per distinct flaw.

What OpenAI actually ran

The pipeline is a chain of agent stages, each handing its output to the next:

1. Scout agents picked 5,034 audit targets, about 2.8 million lines or roughly 7% of the kernel, keeping only code a low-privileged user can reach.
2. Analyst agents produced 2,308 deduplicated candidate bugs within 12 hours.
3. Triage agents reproduced 1,724 of them (74.7%) in isolated virtual machines within 30 hours.
4. Exploit agents built 291 information-leak proofs of concept and the 1,169 root exploits.
5. Variant analysis merged exploits for the same root cause and generated a candidate patch for each of the 948 distinct flaws.

The 30 hours that went round in early headlines covers the reproduction stage only. The whole scan, including manual analysis, took 10 days. The target was the latest kernel at the time, built and run as a stock desktop install of a common distribution with its standard protections switched on. OpenAI does not name the distribution or the kernel version.

Success meant root on that target. That bar needed tightening: in an earlier experiment, 20 of 200 claimed exploits reached root through a different zero-day than the one the agent was assigned. OpenAI added an independent check that each exploit uses its intended bug, and researchers review every exploit, patch and proposed severity before anything goes to maintainers.

How many are new

OpenAI does not say how many of the 948 other researchers had already found. By the end of the 10-day scan, 61 had been fixed upstream, 43 had patches in staging trees and 299 were being reported or discussed publicly, so at least half had no public fix or discussion at that point. OpenAI says it has sent hundreds of reports and patches, starting with the most serious at the kernel community's suggestion, and is releasing the rest gradually through Patch the Planet, the disclosure program it launched in June with Trail of Bits and others.

The trend is the part to plan around. OpenAI's June work with GPT-5.5 Cyber produced 24 LPE exploits. A late-July run with GPT-5.6 Sol found 166 unique LPEs for $513,690. October found more than five times as many, on a kernel that had three more months of hardening. In a sample of 166 exploits, OpenAI and outside kernel exploitation experts identified at least 10 techniques they had not seen before.

OpenAI also pointed the pipeline at an adapted version of Google's kernelCTF, a deliberately hardened kernel with a reduced attack surface. Over 112 hours and $32,936 in API credits it produced 21 privilege escalation exploits and 25 information leaks.

What it means for patch timelines

The fix pipeline from upstream to your servers is now the bottleneck. A patch merged by kernel maintainers still has to be backported by your distribution, packaged, installed and booted. For many fleets that takes weeks, and appliances can lag for months. Each upstream fix is also a public diff that points straight at the bug, and turning a known bug into an exploit is easier than finding it.

Treat an unpatched account that can run code on a Linux host as a possible root account, and plan to receive kernel updates more often than before.

What to do

Shorten the kernel update loop. Track your distribution's kernel security advisories and aim to install and boot new kernels within days on exposed tiers. An installed kernel does nothing until you reboot: compare uname -r with the newest installed package, and check /var/run/reboot-required on Debian and Ubuntu or run needs-restarting -r on RHEL. Where reboots are hard, live patching (Canonical Livepatch, kpatch on RHEL, SUSE Live Patching) covers many fixes in the gap.

Start with the hosts where strangers run code. Multi-tenant hosts, CI/CD runners, shared bastions, container platforms and developer fleets go first, ahead of single-purpose servers where only admins log in.

Cut what an unprivileged user can reach. Each item removes kernel code from a local attacker's reach:

• Unprivileged user namespaces give a normal user root inside a namespace, which opens netfilter and other networking code to them. On Ubuntu 24.04 and later keep kernel.apparmor_restrict_unprivileged_userns=1. Elsewhere, set user.max_user_namespaces=0 on hosts that do not run rootless containers or browser sandboxes, and test first.
• Turn off io_uring where nothing uses it with kernel.io_uring_disabled=2 (kernel 6.6 and later).
• Keep kernel.unprivileged_bpf_disabled at 1 or 2.
• Set kernel.kptr_restrict=2 and kernel.dmesg_restrict=1 so kernel addresses do not leak, which makes the information-leak half of an exploit chain harder.
• Block modules you never load, such as rarely used network protocols, with install <module> /bin/false lines in /etc/modprobe.d/, so an unprivileged request cannot auto-load them.

Put a second kernel between untrusted code and the host. For CI jobs, AI agent sandboxes and customer workloads, gVisor (a user-space kernel that intercepts system calls) or Firecracker microVMs (each workload gets its own kernel) mean a kernel exploit lands in a throwaway boundary. Ordinary containers share the host kernel and do not.

Turn on lockdown where Secure Boot allows. Kernel lockdown (lockdown=integrity) does not stop the escalation, but it stops root from loading unsigned modules or writing kernel memory through /dev/mem, which limits how deep an attacker can dig in after getting root.

Watch for the escalation itself. Exploit attempts often crash first. Alert on general protection fault, BUG: unable to handle and Oops lines in journalctl -k. Add an auditd rule for root processes started by logged-in users, such as -a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=4294967295 -k root_exec, and investigate any that do not trace back to sudo or another approved path. eBPF-based tools such as Falco or Tetragon can alert on a process that gains root outside those paths.

Our safeguarding and hardening work applies these kernel and namespace settings across Linux fleets, and cloud and Kubernetes security covers isolating CI runners and container workloads. If you want to know how exposed your hosts are, open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: OpenAI, A thousand fewer paths to root, Help Net Security, CSO Online, Unite.AI, Interesting Engineering.