OpenAI Found 948 Linux Kernel Flaws. Who Will Fix Them?

Last verified: 5 November 2026. All figures are OpenAI-reported and haven’t been independently audited.

OpenAI says an autonomous agent pipeline found 948 distinct OpenAI Linux kernel vulnerabilities in a single run, each one a working path from an ordinary user account to root. The bill was $1,213,430 in API credits. According to OpenAI’s 4 November research publication, ten days after the scan and manual review finished, 61 of those flaws had been patched upstream.

That second number is the more interesting one. AI is turning kernel bug-hunting into a question of compute. Getting fixes reviewed, merged and onto real machines still runs on human time.

Key Takeaways

• 948 is a count of distinct flaws. OpenAI’s agents found 948 distinct local privilege-escalation vulnerabilities, backed by 1,169 working exploits.
• The funnel matters. 2,308 candidates became 1,724 reproduced bugs. The 291 information-leak PoCs are a separate measurement, not extra root exploits.
• $1,279 is an average API cost, not a price. It’s $1,213,430 in reported API credits divided by 948 flaws, and OpenAI calls it an upper bound.
• Remediation isn’t in that figure. Human review, maintainer time, backports and deployment all cost extra.
• Human checks caught real errors. 20 of 200 early “successful” exploits had reached root through the wrong bug.
• A generated patch isn’t a deployed fix. Ten days after the scan, 61 flaws were patched upstream and 43 had staging patches.
• These are local flaws. An attacker needs existing access first, so isolation and least privilege still limit the damage.
• Discovery now scales faster than repair. The next problem for AI security research is review, disclosure and distribution capacity.

---

Quick Navigation

---

OpenAI Linux kernel vulnerabilities: what happened in the experiment

In mid-October 2026, OpenAI’s security researchers pointed a multi-agent system at the latest Linux kernel master branch. The agents ran on what OpenAI calls an upcoming cyber model, which it hasn’t named or released. Their brief was narrow: find flaws that let a low-privileged local user become root, prove them, and draft a fix for each.

The company’s experiment found 948 distinct local privilege-escalation (LPE) vulnerabilities, backed by 1,169 working exploits and a candidate patch for each distinct flaw. OpenAI also reported 291 proof-of-concept programs for information leaks, a separate and less severe class of bug.

Two context points matter before the numbers. First, the agents audited about 7% of the kernel, not all of it. Second, every figure here comes from OpenAI. The Linux kernel security team hasn’t published its own count, and no outside group has audited the results.

OpenAI also ran the same harness in July with an earlier model, GPT-5.6 Sol. That run found 166 unique LPEs for $513,690, or roughly $3,095 each. In three months, the yield per run rose more than fivefold and the average cost per flaw fell by more than half.

Inside the pipeline behind the OpenAI Linux kernel vulnerabilities

The published methodology describes five stages, each narrowing the work handed to the next.

1. Scouting. Scout agents mapped the kernel’s 40-million-plus lines and picked code a low-privileged user can actually reach. They chose 5,034 audit targets covering about 2.8 million lines, for $3,426 in API credits. A flaw only root can trigger can’t be used to become root, so this filter is the cheapest win in the run.
2. Analysis. Analyst agents read those targets and produced 2,308 candidate findings in about 12 hours, at a cost of $316,549. A candidate is a hypothesis: the model believes some code path is unsafe. Many turn out to be wrong, unreachable or harmless.
3. Dynamic validation. Triage agents then had to prove each candidate. They wrote small proof-of-concept programs and ran them inside isolated virtual machines built with the Kernel Address Sanitizer (KASAN), a debugging tool that flags invalid memory accesses at the moment they happen. Over 30 hours, 1,724 candidates reproduced, a rate of about 74.7%, for $73,330.
   • This step is what separates the run from static analysis. A static tool reports that code looks dangerous. A reproduced finding comes with runtime evidence that the bug fires. OpenAI puts the share of failures caused by wrong analysis at only about 3.1%. Most of the others needed elevated privileges to start, or relied on race conditions and fault injection that are hard to trigger on demand.
4. Exploitation. Exploit agents tried to turn validated bugs into either an information leak or full root access. They worked on virtual machines configured like a stock desktop distribution, with standard kernel self-protection features switched on:
   • SMEP stops the kernel from running code placed in user memory.
   • SMAP stops the kernel from reading or writing user memory unless it means to.
   • KASLR randomises where the kernel sits in memory, so an attacker has to find it first.
   • HARDENED_USERCOPY checks the size and bounds of copies between the kernel and user programs.
   • An exploit that only works with these defences off proves far less. This stage was the most expensive by far, at $775,929.
5. Patching and human review. For each validated flaw, the system worked out the root cause and drafted a candidate patch. It then ran variant analysis, which looks for the same mistake elsewhere and groups exploits that share one fix. Finally, human researchers reviewed each exploit, patch and proposed severity before anything went to kernel maintainers.

How the OpenAI Linux kernel vulnerabilities numbers narrow down

The headline figures measure different things, and mixing them up is the easiest way to misreport this research.

Table: scroll sideways to view all columns when needed.

Measurement	Count	What it counts
Candidate findings	2,308	Suspected flaws flagged by analyst agents
Dynamically reproduced	1,724	Candidates proven to fire in a KASAN virtual machine
Information-leak PoCs	291	Programs that expose kernel memory, not root exploits
Working LPE exploits	1,169	Exploits that reached root on a protected test VM
Distinct LPE vulnerabilities	948	Unique flaws after variant analysis, one candidate patch each

The step from 1,169 to 948 is the one most coverage glosses over. Some flaws were reached by more than one working exploit. Variant analysis grouped exploits by the patch that closes them, so 948 counts distinct problems and 1,169 counts working attacks.

The 291 information-leak programs sit to one side. They show a bug can expose memory an attacker shouldn’t see, which can help defeat KASLR, but they aren’t additional root exploits. OpenAI also hasn’t published how many reproduced bugs were judged unexploitable, so the gap between 1,724 and the exploit counts isn’t fully explained.

OpenAI Linux kernel vulnerabilities: what $1,279 per flaw really means

OpenAI reported that the run cost $1,213,430 in API credits from start to finish. Divided across the distinct flaws, that works out as:

$1,213,430 ÷ 948 ≈ $1,280

OpenAI’s own write-up gives the average as about $1,279. Here’s where the money went, using the stage costs OpenAI reported:

Table: scroll sideways to view all columns when needed.

Pipeline stage	Reported API cost	Share of total
Scouting	$3,426	0.3%
Candidate analysis	$316,549	26.1%
Dynamic validation	$73,330	6.0%
Exploit development	$775,929	63.9%
Not itemised in the stage breakdown (our subtraction)	$44,196	3.6%
Total	$1,213,430	100%

Finding the bugs was cheap. Proving they could become root was where nearly two-thirds of the budget went.

Inside that exploitation stage, success and failure cost very different amounts. Successful attempts averaged about $359. The 69 attempts that never worked cost far more each, mostly because agents kept retrying stubborn race conditions. A race condition depends on two operations happening in a precise order, so an agent can spend hours rerunning a test that fails because of timing, not because the analysis was wrong.

That makes the $1,279 figure useful as a signal and risky as a benchmark. It’s the reported API spend divided by distinct flaws, nothing more. It doesn’t include:

• the salaries of the researchers who reviewed every exploit and patch
• maintainer time spent triaging, reviewing and merging fixes
• distribution packaging, backports or rollout to real servers
• the cost of building the harness itself
• any guarantee that another codebase or model would produce the same yield

OpenAI also frames the costs as an upper bound. The run was designed to measure what the model could do, not to minimise spend, and the company says better harness engineering could bring the costs down. Read the number as the price of one experiment, not as a market rate for kernel bugs.

OpenAI’s bounty comparison needs the same caution. Priced at historical Pwn2Own and TyphoonPWN rates, it values the haul at $18.9 million to $66.3 million. Google’s kernelCTF programme pays $71,337 per eligible exploit, but only for 0-days against a hardened target, and only once the patch lands upstream. Many of the 948 flaws would never qualify.

Why patching the OpenAI Linux kernel vulnerabilities is the harder problem

Here is the status OpenAI reported ten days after the scan and manual review:

Table: scroll sideways to view all columns when needed.

Status after 10 days	Count	What it means
Patched upstream	61	A fix has been merged into the mainline kernel
Staging patches	43	A fix is queued in a maintainer tree, not yet in mainline
Publicly reported and discussed	299	The flaw is being handled in public kernel discussion
Still in the reporting pipeline	Not stated	OpenAI hasn’t given a count for the remainder

These categories describe stages, not a tally of fixes. Adding them up and calling the result “fixed” would be wrong, and so would reading the gap as maintainers ignoring reports. OpenAI says it started with the most critical flaws, following Linux kernel community guidance, and sent hundreds of reports and patches. It’s reporting the rest through Patch the Planet, its open-source effort with partners including Trail of Bits, Calif and HackerOne.

Ten days is a short window for kernel work. The kernel’s own security process asks maintainers to verify a report, agree a fix and get it merged. Publication of a fix can be held back for at most seven days once the release process starts, or 14 by agreement. Each fix also has to pass review, regression testing and compatibility checks across a huge range of hardware.

Upstream is only the first stop. A patch in mainline has to be backported to the stable and long-term kernels that most organisations actually run. Distributions like Debian, Ubuntu and Red Hat package it, test it and issue advisories on their own schedules. Then every administrator has to install the update and reboot or live-patch. A fix that’s “in Linux” can take weeks or months to reach a given server.

The kernel documentation now has specific rules for AI-assisted reports: keep them concise, avoid speculative impact claims, and include a tested reproducer and fix. It also says bugs found with AI assistance should be treated as public, because someone else’s tool may find them too.

That isn’t a hypothetical concern. In May, the embargo on Dirty Frag, a kernel LPE, broke early amid a parallel discovery of a related bug, iTnews reported. The researcher behind the second bug said no AI was involved, but maintainers warned that LLM-assisted research makes parallel discovery more likely. When several teams’ agents scan the same code, the window for quiet, coordinated repair gets shorter.

Why AI-generated security patches still need humans

The most telling detail in OpenAI’s report is a failure it caught. In an early exploitation run, the pipeline reported 200 successful LPE exploits. Human review found that 20 of them had reached root through a different, unknown vulnerability, not the one the agent had been assigned.

The cause was a loose definition of success. The test asked whether the agent got a root shell. Those 20 agents did, just by another route. A result like that looks like a pass, but it ties the exploit to the wrong bug, which means the wrong patch, the wrong severity and a real flaw left unrecorded. OpenAI tightened the task constraints and added an independent check that every final exploit used the vulnerability it was assigned.

The same discipline applies to patches. OpenAI says early AI-written patches were sometimes correct but padded with unnecessary code or out of step with kernel style, and took further iterations to become minimal, conventional and complete across variants. In a few cases, the system caught problems in human-written patches before they merged.

Independent research urges caution about automated fixes generally. In August, 1Password’s Off-By-1 Labs tested 6,080 patches from two frontier models against six real vulnerabilities, including a Linux privilege-escalation flaw. It found that 53.9% failed to fix the bug, introduced a new one or both, SecurityBrief reported. Those were one-shot patches, not OpenAI’s reviewed pipeline, so the numbers don’t transfer. They do show why a generated patch is a proposal, not a fix.

We made a similar point about the hidden costs of AI coding agents: generating code is cheap, but review, testing and rework are where the real cost sits. Kernel security is that problem at its sharpest.

What the OpenAI Linux kernel vulnerabilities mean for Linux security

A local privilege-escalation flaw lets someone who already has limited access to a machine become root. It doesn’t, on its own, let a stranger on the internet break into a server. An attacker first needs a foothold: a user account, a compromised web app, a malicious package or code running in a container.

That still makes LPEs serious in plenty of places:

• shared servers and multi-user systems, such as university or research clusters
• cloud hosts and CI runners that execute untrusted code
• containers, where a kernel flaw can break the isolation boundary between workloads
• developer laptops, where a malicious dependency can run as the user
• any system where an attacker has already compromised one account

OpenAI hasn’t published affected kernel versions, CVE identifiers or a list of vulnerable distributions. It has also withheld details of ten exploitation techniques that it and outside kernel specialists considered new. Treat any list of affected versions circulating online with suspicion until OpenAI or the kernel community publishes one.

For administrators, the practical advice is unexciting and correct. Follow your distribution’s security advisories and apply supported kernel updates promptly as fixes arrive. Reduce who and what can run code locally. Use least privilege, sandboxing and container isolation, and monitor for unexpected privilege changes. Defence in depth matters more when the number of known paths to root is rising.

Beyond OpenAI: what autonomous security research means for open source

OpenAI isn’t alone. Anthropic’s Project Glasswing, announced in April, used Claude Mythos Preview to find thousands of zero-days across major operating systems and browsers, including chained Linux kernel flaws that turned user access into full control. For Gemini 4 Carbon, which we covered in our look at its cybersecurity scores, Google reports strong results on benchmarks for finding and fixing vulnerabilities.

These efforts measure different things, from bugs found to exploits against hardened targets, and almost none report patches accepted and deployed. Raw counts aren’t comparable. On Google’s kernelCTF environment, which has a reduced attack surface, OpenAI’s pipeline produced 21 LPE exploits and 25 information-leak PoCs in 112 hours for about $32,936. The target was built to be hard, and the haul shows it.

The pattern holds well beyond the kernel. When VicOne used AI-assisted research on robotics software, it reported 28 zero-day findings in under two days, as we covered in our robotics security analysis. Discovery speeds up, and patching doesn’t.

The open question is who absorbs the extra load: more reports, more duplicates and more automated patches, often from several labs scanning the same code. Programmes like Patch the Planet and Glasswing’s funding for open-source security groups put some money and expert triage on the maintainers’ side. Whether that scales is the test for every lab now publishing big vulnerability counts.

AI changes how much security research can be generated. It doesn’t change who decides what gets trusted and merged.

Frequently asked questions

What are the OpenAI Linux kernel vulnerabilities?

They’re 948 distinct local privilege-escalation flaws that OpenAI’s autonomous agents found in the Linux kernel in October 2026. Each one let a low-privileged user gain root on a test machine with standard protections enabled.

How did OpenAI find 948 distinct Linux kernel vulnerabilities?

It used a five-stage agent pipeline that scouted reachable code, flagged candidates, reproduced them in KASAN virtual machines, built exploits and drafted patches. Humans reviewed the results before reporting.

What is a local privilege-escalation vulnerability?

It’s a flaw that lets someone who already has limited access to a system gain higher privileges, usually root. It isn’t a way in from outside; the attacker needs a foothold first.

How much did it cost to find the OpenAI Linux kernel vulnerabilities?

OpenAI reported $1,213,430 in API credits for the full run, or about $1,279 per distinct flaw. That excludes staff time, maintainer work and deployment.

What is the difference between 1,169 exploits and 948 vulnerabilities?

1,169 is the number of working exploits, and 948 is the number of distinct flaws behind them. Some flaws were reached by more than one exploit, and variant analysis grouped them by the patch that fixes each one.

Have all the OpenAI Linux kernel vulnerabilities been patched?

No. Ten days after the scan, OpenAI reported 61 patched upstream, 43 with staging patches and 299 being discussed publicly. Even an upstream fix still has to reach distribution kernels and individual servers.

Can the OpenAI Linux kernel vulnerabilities be exploited remotely?

Not on their own. They’re local privilege-escalation flaws, so an attacker first needs some access to the machine, such as a user account or code running in a container.

Why do AI-generated security patches need human review?

Because a patch can look right and still be incomplete or wrong. OpenAI’s early patches needed several iterations, and its pipeline once tied 20 exploits to the wrong bug.

How does AI change vulnerability research?

It makes finding and proving bugs far cheaper and faster. Validation, disclosure and patch review still depend on human experts and maintainers.

What should Linux administrators do about the OpenAI Linux kernel vulnerabilities?

Follow your distribution’s security advisories and apply supported kernel updates as they’re released. OpenAI hasn’t published affected versions, so there’s no specific emergency patch to chase yet.

---

Keep reading

Here are the latest posts from the blog.