OpenAI's 948 Linux Root Exploits: What an AI Kernel Pipeline Means for Patching and Agent Sandboxes

OpenAI says an autonomous agent pipeline reproduced 1,724 Linux kernel vulnerabilities and built 948 working local privilege escalation (LPE) exploits in one run costing $1,213,430, and that patches are now going to maintainers. The report, "A thousand fewer paths to root", was published on November 4, 2026. The takeaway for people who run coding agents is practical: an unpatched Linux machine where something unprivileged can run code should now be treated as one step from root.

This is a vendor report about a controlled research environment, not a disclosed attack. No CVE list accompanies it, and the findings are being reported to Linux maintainers over time. Below is what the pipeline did, which numbers are measured versus hypothetical, what is fixed, and what to change on agent hosts.

TL;DR

What did OpenAI build?

OpenAI describes a five-stage pipeline powered by an "upcoming cyber model":

1. Vulnerability discovery. "Scout" agents read the kernel tree and choose audit targets based on reachability by low-privileged users and security relevance. They picked 5,034 targets, about 2.8 million lines or roughly 7% of the kernel, for $3,426. "Analyst" agents then scanned those targets and produced 2,308 deduplicated candidate findings within 12 hours, at a cost of $316,549.
2. Dynamic validation. A triage agent wrote a proof of concept for each candidate and ran it in an isolated virtual machine on a kernel built with KASAN (Kernel Address Sanitizer), iterating until it reproduced the behaviour. Within 30 hours it reproduced 1,724 vulnerabilities, about 74.7% of candidates, for $73,330. OpenAI says only 3.1% of candidates reflected incorrect analysis by the model.
3. 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. They produced 291 information-leak proofs of concept and 1,169 working LPE exploits.
4. Patch generation. After variant analysis, the system generated 948 distinct patches, one per unique vulnerability behind the exploits. OpenAI uses 948 as its count of unique LPEs.
5. Human review. Security researchers review the exploit, patch and severity before anything goes to maintainers.

Each finding is bundled as a root-cause analysis, a minimal crashing proof of concept, a candidate patch and a full exploit.

Which numbers are measured and which are hypothetical?

The measured numbers are the funnel above and the cost: $1,213,430 in total, or $1,279 per LPE exploit. OpenAI also reports that a successful exploit averaged $359 in credits, and that failed attempts on hard cases such as race conditions cost far more per case than successes. It says harness engineering and give-up conditions could cut costs, so the totals are "more an upper bound."

The hypothetical number is the bounty comparison. OpenAI applies historical Pwn2Own ($20,000) and TyphoonPWN ($70,000) payouts to 948 exploits to get $18.9 million to $66.3 million. Nobody paid that; it is a scale illustration. On an adapted kernelCTF environment with reduced attack surface, the pipeline reported 21 LPE exploits and 25 information-leak proofs of concept for about $32,936, compared with 26 confirmed 0-day LPEs accepted by kernelCTF in 2026 at the time of writing. OpenAI also says the agents "discovered and used at least 10 novel Linux exploitation techniques."

The target was a stock desktop operating system under the threat model used in security competitions, not a weakened build. That makes the result more relevant than a lab-only crash, though the report does not name the distribution.

What is actually fixed?

This is the part that decides your response. OpenAI writes that while the scan was running for 10 days, over 100 Linux LPEs were patched or had staging patches from other contributors, with about 300 more being publicly discussed. When the autonomous scan and manual analysis finished, 61 LPEs were patched upstream, 43 had staging patches and 299 were being reported and discussed publicly. Following guidance from the Linux kernel community, OpenAI began with critical vulnerabilities, says it has "already sent out hundreds of reports and patches," and is working with Patch the Planet partners to send the rest gradually.

So most of the 948 are not yet in a released kernel you can install. Staged disclosure is intentional, and we cannot list affected CVEs because none are published in the report. What you can do is stay current: fixes arrive through ordinary stable kernel releases. For background on how OpenAI's disclosure program works, see our analysis of the Patch the Planet disclosure framework.

Why does this matter if I run AI coding agents?

OpenAI's own conclusion is blunt: "having access to a low-privileged account on an operating system, that isn't up-to-date on its latest available patches should be considered functionally equivalent to root access for a well-resourced threat actor."

A coding agent is, in effect, a low-privileged account that executes commands you did not write. If a prompt injection, a malicious skill or a poisoned dependency gets an agent to run attacker-chosen code, local root is the next step on a host with an old kernel. From root, an attacker can read other users' credentials, tamper with the monitoring on the box and persist. We have seen the earlier steps of that chain in recent incidents, such as a malicious AGENTS.md hijacking Codex and Claude Code and attackers running agents to reach domain admin.

The report also shows the trend line. OpenAI says its October pipeline found more than five times as many novel LPEs as a GPT-5.6 Sol run in July, "despite three months of hardening between the scans." It expects that frontier models will likely find any existing vulnerabilities in a project and that even less capable models may be able to build exploits once a bug is disclosed. Anthropic described the same shift in AI-built exploit chains for Chrome, Linux MPTCP and Windows QUIC. The gap between a public patch and a working exploit is getting shorter.

What this means if you run AI coding agents

These steps come from standard Linux practice and OpenAI's own recommendations; none is specific to this report's bugs.

• Update the kernel and reboot. Install your distribution's latest kernel package and actually restart; a staged patch does nothing on a running old kernel. Check with uname -r before and after.
• Turn on automatic security updates on laptops, CI runners and self-hosted agent boxes, and track your distribution's kernel advisories during the coming weeks of staged disclosure.
• Do not run agents directly on a host that holds valuable credentials. OpenAI points to "sandboxes and isolation approaches like Firecracker and gVisor" for limiting blast radius. Our posts on the Capsem VM sandbox for coding agents and Google's microVM with no credentials inside the sandbox cover practical designs.
• Keep secrets out of the agent's reach. If the agent user cannot read long-lived tokens, a local root exploit has less to take on the first hop. Rotate anything an agent session could have exposed.
• Remove unneeded kernel attack surface where you can, for example services that expose in-kernel network servers. Our write-up of the KSMBD flaws shows the check, and the TCP use-after-free status post shows how to separate a claim from a patch.
• Review logs for odd privilege changes after an agent session: unexpected sudo, new setuid files, new users or cron entries, and agent commands that touch /proc, /sys or kernel modules.

What Beam can and cannot do here

Beam cannot stop a kernel exploit. It is not a kernel sandbox, and once code is running locally with a working LPE, hook-based controls can be bypassed. What it does is act earlier in the chain. For Claude Code and Codex, Beam's PreToolUse hooks can flag and, under workspace enforce policy, deny risky commands such as credential reads and privilege-escalation attempts before they run, and it keeps an on-device record of what the agent did, with secrets redacted before storage. Its skill and MCP scanner uses heuristics, not semantic malware analysis, so it can miss novel payloads. Policy is fail-open if no cached policy is available. See what Beam watches and how it works. Treat Beam as one layer, next to patched kernels and VM isolation, not a replacement for either.

What are the limits of this report?

It is OpenAI's own account. The cyber model is unreleased, the targeted distribution is unnamed, and the 948 exploits are not published. We could not independently reproduce any of it, and the per-vulnerability list will only emerge as maintainers publish fixes and CVEs. Counts also shift: OpenAI uses 948 distinct patches as its unique-LPE number, while the exploit stage produced 1,169 working exploits, so some exploits share a root cause. Treat the headline as a credible signal about speed and cost, not as a list of 948 open holes.

Frequently asked questions

What did OpenAI actually report?

OpenAI says a prototype pipeline using an upcoming cyber model analyzed 2,308 candidate Linux kernel findings, reproduced 1,724 vulnerabilities and produced 948 working local privilege escalation exploits against a stock desktop Linux distribution in a mid-October 2026 run. The run cost $1,213,430 in API credits. A human researcher reviews results before they are reported to maintainers.

Are the 948 vulnerabilities fixed?

Not all of them. OpenAI says that when the scan finished after 10 days, 61 local privilege escalations were already patched upstream, 43 had staging patches and 299 were being reported and discussed publicly. It has sent hundreds of reports and patches for critical bugs and is releasing the rest gradually with Patch the Planet partners.

Does this mean my Linux server can be rooted remotely?

No. These are local privilege escalations: an attacker needs to already run code as an unprivileged user on the machine. The risk is that any foothold, such as a compromised dependency or a prompt-injected agent running commands, can be turned into root on an unpatched kernel.

What should I do on machines that run coding agents?

Install your distribution's latest kernel and reboot, keep unattended security updates on, and run agents in a VM or microVM boundary rather than directly on a host with valuable credentials. OpenAI itself recommends sandboxes such as Firecracker and gVisor to limit the blast radius.

Can Beam stop a kernel privilege escalation?

No. Beam is hook-based monitoring and deny for agent actions, not a kernel sandbox. It can flag and, for Claude Code and Codex, deny risky commands before they run, and show what an agent did, but it cannot contain an exploit once code is running locally.

Is the pipeline available to attackers?

The pipeline and the upcoming cyber model are OpenAI's and are not released. OpenAI argues, however, that frontier models will find most bugs in a given project and that even less capable models may build exploits once a bug is disclosed, so the defensive window is shrinking.

Related reading

• OpenAI Patch the Planet disclosure framework
• Anthropic's AI-built exploit chains: Chrome 156, Linux MPTCP and Windows QUIC
• Capsem: a VM sandbox for AI coding agents
• Linux KSMBD flaws posted before a fix
• Source: OpenAI, "A thousand fewer paths to root" (November 4, 2026)

Figures and status are accurate as of November 5, 2026, based on OpenAI's published report. Patch status will change as maintainers release fixes; check your distribution's advisories.