OpenAI finds 948 Linux root flaws, but fixes need review

OpenAI’s prototype security-research pipeline found Linux kernel flaws that could let an unprivileged local user become root, producing 948 unique local privilege escalation findings and candidate fixes.

OpenAI’s research write-up describes a pipeline powered by an upcoming cyber model, with human researchers reviewing its output before vulnerabilities were reported.

What do the 948 Linux kernel flaws actually represent?

The 948 figure counts what OpenAI calls unique local privilege escalation (LPE) vulnerabilities: flaws that may let an attacker with an existing, unprivileged local foothold gain root access. This is not evidence of 948 remotely exploitable flaws.

Linux underpins Android devices, cloud infrastructure and supercomputers, and its kernel contains more than 40 million lines of code. OpenAI chose that codebase for the test.

The published accounts use different working-exploit totals. They also attach different meanings to those totals, which matters when reading the headline number:

OpenAI’s detailed account explains the difference. Variant analysis connected the working exploits to Linux kernel flaws addressed by 948 distinct patches. The raw exploit count measures working exploits; the unique-LPE count groups them by the Linux kernel flaws those patches address.

The scan targeted the latest Linux kernel in mid-October 2026, and Unite.AI dates OpenAI’s reporting to November 4, 2026. The widely cited 30 hours belongs to dynamic validation: the system reproduced 1,724 vulnerabilities during that stage. It is not the duration of the whole discovery-to-review campaign. OpenAI says the autonomous scan and manual analysis finished after 10 days.

How Scouts, Analysts and KASAN turn leads into reproducible bugs

The five-stage workflow

1. Discovery: Scouts select the audit targets. Analysts scan those selected targets for candidate vulnerabilities.
2. Dynamic validation: Agents attempt to reproduce each candidate in isolated environments, preserving the runtime evidence from those attempts.
3. Exploitability assessment: Agents test whether the validated flaws could support information disclosure or local privilege escalation.
4. Patch generation: Agents produce candidate fixes for the vulnerabilities they have identified.
5. Human review: Researchers review the exploit, patch and proposed severity before reporting each finding to maintainers.

From selected code to runtime evidence

Scouts read folders and files, selecting 5,034 audit targets at a cost of $3,426 in API credits. Those targets covered about 2.8 million lines, roughly 7% of the kernel. Analysts read each target to understand its behavior and threat model, then identify vulnerabilities. Within 12 hours, they produced 2,308 deduplicated findings. That stage cost $316,549. Unite.AI corroborated the target coverage, finding count and timing reported for this work.

Validation required low-privileged reachability, no special capabilities and measurable evidence of memory corruption. For each candidate, a triage agent generated a proof of concept and ran it in an isolated virtual machine whose kernel had Kernel Address Sanitizer (KASAN) running. The agent watched program output and the system console, refining the program until it reproduced the reported behavior or exhausted the potential triggers it could try. Those 1,724 reproductions cost $73,330 in API credits.

Why failure to reproduce does not establish a false positive

Most remaining findings either required elevated privileges or could not be reproduced within the time budget. Some were difficult races. Others depended on an allocation failure at a particular line or on time-consuming refcount wraparound. Each could obstruct validation without making the analysis wrong. OpenAI attributed only 3.1% to incorrect analysis that assumed an impossible condition; a failed reproduction attempt alone did not justify putting a finding in that category.

Generating a proof of concept cost more than static assessment, while runtime attempts to validate true positives and false positives cost similar amounts. The useful place to reject an incorrect lead is therefore before that runtime investigation.

Testing exploitability without weakening the target or trusting a root shell

A shell running as root does not establish that the agent exploited the vulnerability it was assigned.

1. Screen permissively. An agent statically reviewed reports, crash logs and relevant source code. It discarded cases without plausible exploitation paths, but avoided rejecting serious findings prematurely. That left 313 information-leak candidates and 1,238 local privilege escalation (LPE) candidates for further assessment.
2. Test without weakening the desktop target. ExploitDev agents worked in isolated VMs with SMEP, SMAP, KASLR and HARDENED_USERCOPY enabled.

OpenAI reports these outputs and API costs for the assessment stage:

The independent check followed an early failure. Human reviewers examined 200 apparent successes and found that 20 had reached root through a different zero-day, not the assigned vulnerability. OpenAI tightened the task constraints and added verification that each exploit actually used the vulnerability assigned to it.

During kernelCTF privilege-transition experiments, an Analyst agent encountered an unexpected crash and traced it to a QEMU TCG flaw. An ExploitDev agent subsequently developed a local privilege escalation exploit for it. Manual review confirmed that upstream had already fixed the flaw, but the experiment’s release build still contained it. Treat maintained virtualization infrastructure as part of the laboratory boundary, and do not assume that isolation makes the harness itself trustworthy.

Why 948 candidate fixes do not mean 948 merged Linux patches

The Hacker News says the pipeline “validate[d] and patch[ed] 948 local privilege escalation vulnerabilities.” Unite.AI is explicit that the fixes remain candidates for maintainer review and that 948 does not count merged patches. OpenAI’s primary account supports that narrower reading: candidate patches, not 948 confirmed upstream merges.

What reviewers receive—and why iteration matters

The completed review bundle contains a root-cause analysis, a minimal crashing proof of concept, a candidate patch and a full exploit. OpenAI describes the work of generating and reviewing the patches in these terms:

1. Give the model the relevant source code and instructions to perform static checks, follow development practices in nearby code and analyze variants so that the fix is complete.
2. Improve patch generation through additional instructions and iteration. Initial patches could stop the proof of concept yet still include unnecessary code, potential performance costs, departures from coding style or incomplete coverage of related vulnerabilities.

In a few cases, the prototype found problems in human experts’ patches, and those problems were corrected before merging.

What had actually reached upstream

OpenAI said it had sent hundreds of critical-vulnerability reports and patches, while coordinating the remaining submissions through Patch the Planet partners. After ten days of scanning and manual analysis, it reported the statuses below. Unite.AI also covered these figures, which describe how far the findings had progressed:

What $1.213 million bought—and what the model comparisons cannot prove

OpenAI’s mid-October campaign produced 948 unique LPEs for $1,213,430 in API credits, approximately $1,279 each.

Each campaign targeted the latest Linux kernel master branch available at the time, so the comparison does not isolate model capability against unchanged code. OpenAI also calls the costs upper bounds for a research workflow focused on methodology rather than optimization. These are API costs; they do not represent the full operational cost of running the workflow.

Successful-exploit pricing hides expensive failures

OpenAI reports a $359 average to develop a successful exploit. That prices successful exploit development, not the whole campaign, and is narrower than end-to-end spending per unique LPE. The attempt-level breakdown reports its case counts and average API costs separately, as shown here:

A few difficult Linux kernel flaws, including race conditions, drove the expensive failures. OpenAI says stopping after one hour without progress would have significantly reduced exploit-development costs.

The narrower evidence for novelty and orchestration

OpenAI identified ten reportedly novel techniques in a sample of 166 exploits: two persistent elastic objects for spraying the target kernel cache, two page-grooming techniques for reliability, five data-only techniques for direct privilege escalation or arbitrary writes, and one arbitrary-type-confusion technique. Independent kernel-exploitation experts also considered those techniques new.

The techniques were formatted for model use, placed in the agent’s environment and accompanied by explicit prompts to use them. For the stronger model, however, OpenAI judged the marginal benefit too small to justify maintaining the heavier orchestration and removed it.

The kernelCTF results and the limits of hypothetical bounty returns

OpenAI’s additional kernelCTF experiment produced 25 information-leak proofs of concept and 21 local privilege escalation (LPE) exploits over 112 hours, at approximately $32,936 in API credits. This was an adapted environment, not an unchanged kernelCTF target: OpenAI removed SLAB_VIRTUAL because the mitigation was incompatible with the latest kernel it tested.

KernelCTF targets a hardened Linux kernel with reduced attack surfaces. In this campaign, vulnerability discovery consumed 83.7% of API spending.

Potential rewards are not awarded revenue

OpenAI estimated approximately $1.5 million in potential bounties, about 45x API cost, if all 21 vulnerabilities were accepted. Unite.AI reports $71,337 per eligible exploit, at least 70% stability across 20 runs, and qualifying zero-day requirements.

For the stock-desktop experiment, OpenAI applied historical Linux LPE rewards from Pwn2Own and TyphoonPWN—$20,000 and $70,000 respectively—to 948 exploits. That produced a hypothetical valuation of $18.9M–$66.3M, approximately 16x–55x API cost.

OpenAI characterized the pipeline as net profitable using public payout amounts. I’d treat those figures as conditional reward comparisons, not demonstrated revenue or a general model of deployment economics.

Who should not deploy autonomous kernel research

I’d advise teams without kernel-security expertise, isolated and monitored infrastructure, independent exploit verification, patch testing, or capacity for coordinated maintainer review against unattended kernel research or automatic production remediation.

The dual-use trade-off is direct: The Hacker News reports that the capabilities helping defenders also reduce attackers’ discovery and exploitation costs. It attributes the broader disclosure figures below to Google Threat Intelligence Group. Those figures concern vulnerability disclosures, rather than only the findings produced by OpenAI’s experiment:

Those figures do not establish that OpenAI’s pipeline caused the increase. The Hacker News also reports the NCSC’s warning that faster AI-assisted discovery and patching still leave systems exposed without correct, widespread deployment.

A defender’s next steps: update, revalidate and submit reviewable fixes

1. Update before experimenting. Keep deployed kernels and virtualization software current.
2. Revalidate before reporting. Check current upstream code, including merges made after the original scan. Deduplicate related variants and distinguish unresolved findings from issues already fixed or publicly discussed. This reduces obsolete reports and unnecessary maintainer review.
3. Set patch acceptance checks. Require functional correction, regression and performance testing, minimal changes, static checks and consistency with nearby coding conventions. Use adversarial review to test bypasses, alternate attack paths and related variants. Stopping the original reproducer is one result to check, not the acceptance criterion by itself.
4. Measure useful outcomes and revisit the workflow. I’d track validated and unresolved findings, review burden, accepted fixes and cost per useful result—not raw agent output—as a practical response to the reported bottlenecks. Reassess model capability, orchestration and stopping conditions over time. When capabilities improve, rescan previously audited code rather than treating an earlier audit as the final pass or assuming that its results settle later work.