OpenAI Uses AI to Discover 948 Linux Privilege Escalation Vulnerabilities

OpenAI has detailed an autonomous vulnerability research pipeline that discovered and validated security flaws in the Linux kernel, generated working exploits and produced candidate patches for human review.

In a research run conducted in mid-October 2026, the pipeline identified 2,308 candidate findings, dynamically reproduced 1,724 vulnerabilities and ultimately identified 948 distinct local privilege escalation (LPE) vulnerabilities. These flaws could allow an unprivileged local user to gain root access on an affected system.

The research used an upcoming OpenAI cyber model to automate several stages of vulnerability research, including code analysis, dynamic validation, exploitability assessment and patch generation.

OpenAI reports that the full run cost $1,213,430 in API credits, equivalent to approximately $1,279 per distinct LPE vulnerability. The company says human security researchers reviewed the results before vulnerabilities and candidate patches were reported to maintainers.

The work is part of OpenAI's broader Patch the Planet initiative, which aims to help secure critical open-source software through vulnerability discovery and coordinated remediation.

Why OpenAI Focused on the Linux Kernel

The Linux kernel is used across a wide range of computing environments, including Android devices, cloud infrastructure and supercomputers.

OpenAI selected it as a research target because of its scale and security relevance. The kernel contains more than 40 million lines of code and exposes multiple attack surfaces through system calls, networking, filesystems and device drivers.

Reviewing such a large codebase manually can be resource-intensive. OpenAI's research also highlights a separate challenge: identifying a potential vulnerability is only the beginning. Researchers must determine whether the issue can be reproduced, what security boundary it crosses and whether it creates a meaningful security risk.

The pipeline was designed to automate much of that process, reducing the number of findings requiring manual investigation while generating technical evidence that researchers and maintainers could review.

Inside the Autonomous Vulnerability Research Pipeline

OpenAI's prototype uses five main stages to move from potential code weaknesses to reviewed vulnerability reports.

1. Vulnerability discovery: AI agents identify security-relevant areas of the Linux kernel and scan them for potential flaws.

2. Dynamic validation: Agents attempt to reproduce candidate findings in isolated virtual machines.

3. Exploitability assessment: The system tests whether validated vulnerabilities can enable information disclosure or local privilege escalation.

4. Patch generation: Agents produce candidate code changes intended to address identified vulnerabilities.

5. Human review: Security researchers examine the exploit, patch and proposed severity before reporting the findings to maintainers.

The final output includes root cause analysis, a minimal crashing proof of concept, a candidate patch and a full exploit. These materials help human researchers assess the vulnerability and prepare fixes for upstream review.

How AI Agents Identified Vulnerability Candidates

The discovery process used two groups of agents: Scout agents and Analyst agents.

Scout agents narrowed the audit scope

The Scout agents examined Linux kernel folders and files to identify areas worth investigating. Their prioritization considered whether code could be reached by low-privileged users and whether it was security-relevant.

This stage identified 5,034 audit targets, covering approximately 2.8 million lines of code. OpenAI says this represented roughly 7% of the Linux kernel codebase.

The Scout stage cost $3,426 in API credits.

Analyst agents produced candidate findings

The selected audit targets were then passed to Analyst agents. These agents examined the assigned code, considered its threat model and searched for potential vulnerabilities.

Within 12 hours, the agents produced 2,308 candidate findings after deduplication. This stage cost $316,549 in API credits.

However, OpenAI emphasizes that a candidate finding is not automatically a confirmed vulnerability. Static analysis can identify suspicious code paths that may not be exploitable in practice. The next stage therefore focused on reproducing the reported behavior.

Dynamic Validation Reproduced 1,724 Findings

OpenAI used triage agents to determine whether candidate findings could be reproduced.

For each candidate, an agent generated a proof of concept and ran it in an isolated virtual machine using a Linux kernel configured with Kernel Address Sanitizer (KASAN). The agent examined program output and system console information, then iteratively refined the proof of concept until it reproduced the reported behavior or exhausted the available approaches.

Within 30 hours, the system reproduced 1,724 of the 2,308 candidate findings, approximately 74.7%.

OpenAI says most findings that could not be validated involved conditions such as:

• Requirements for elevated privileges.

• Difficult race conditions.

• Specific fault-injection requirements.

• Time-consuming validation conditions, including reference-count wraparound.

The company also reports that 3.1% of the candidate findings reflected incorrect model analysis, where the reported vulnerability depended on an impossible condition.

The validation stage cost $73,330 in API credits.

This distinction between candidate findings and reproduced vulnerabilities is important. The pipeline did not treat every alert as a confirmed security flaw. It attempted to produce runtime evidence before advancing findings to exploitability assessment.

Exploitability Assessment Identified 948 Distinct LPE Vulnerabilities

After validation, the system assessed which findings could produce meaningful security consequences.

An initial screening agent reviewed vulnerability reports, crash logs and relevant source code. The screening was deliberately permissive to avoid discarding potentially serious issues, while filtering findings without a plausible exploitation path.

This reduced the results to:

• 313 information leak candidates

• 1,238 local privilege escalation candidates

Exploit-development agents then tested the candidates in isolated virtual machines configured with protections enabled in a standard Linux distribution. These included Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) and HARDENED_USERCOPY.

The agents generated 291 information leak proofs of concept and 1,169 working local privilege escalation exploits.

OpenAI then performed variant analysis and developed 948 distinct patches for the vulnerabilities behind those exploits. The company uses the 948 figure to represent the number of unique LPE vulnerabilities identified.

The distinction matters: 1,169 refers to working exploits produced during the exploit-development stage, while 948 represents the distinct LPEs after variant analysis.

OpenAI reports that the exploitation stage cost $775,929 in API credits. Developing an LPE candidate was more expensive on average than processing an information leak candidate because it required additional work, including exploitation strategy planning, identifying suitable vulnerable objects and bypassing mitigations.

AI-Generated Patches and Human Review

The pipeline did not stop after producing exploits. It also generated candidate patches for identified vulnerabilities.

OpenAI provided the model with relevant source code and instructions covering patch-writing practices. These included running static checks, following coding conventions used in nearby code and examining related code for variants of the same vulnerability.

The company found that early patch-generation attempts could produce functionally correct fixes for a proof of concept while introducing other problems. Some patches contained more code than necessary, deviated from existing conventions, potentially affected performance or failed to address related variants.

OpenAI says additional instructions and iterative review improved patch quality. In some cases, the research prototype also identified issues in patches written by human experts, which were corrected before being merged.

The company has already sent hundreds of reports and patches for critical vulnerabilities, following guidance from the Linux kernel community. It is working with Patch the Planet partners to report and patch additional findings.

The research does not mean that all 948 vulnerabilities have already been fixed or that all candidate patches have been accepted and merged. OpenAI describes the patches as part of an ongoing reporting and remediation process.

Linux Maintainers Were Already Patching Vulnerabilities

OpenAI says the Linux kernel community was actively addressing vulnerabilities while the research was underway.

During the 10-day period covering the scan and manual analysis, the company observed:

• 61 LPE vulnerabilities already patched upstream.

• 43 LPE vulnerabilities with staging patches.

• 299 additional LPE vulnerabilities being publicly reported and discussed.

These figures describe the activity observed during the research period. They should not be interpreted as a count of vulnerabilities fixed by OpenAI's pipeline alone.

OpenAI says automated triage systems should account for this rapid patching cycle. Rechecking findings against the latest kernel code can help researchers avoid duplicate or outdated reports and focus attention on unresolved issues.

The company also recommends rescanning previously audited code as model capabilities improve, since stronger models may identify vulnerabilities that earlier systems missed.

A More Capable Model Found More Vulnerabilities

OpenAI compared the mid-October 2026 research run with an earlier campaign conducted in late July 2026.

OpenAI says the newer cyber model identified and exploited more than five times as many distinct LPE vulnerabilities as the earlier run, despite three months of hardening between the scans.

Both campaigns examined the latest Linux kernel master branch available at the time.

The comparison suggests that model capability can materially affect the results of automated vulnerability research. It also highlights why previously audited software may need to be reviewed again as more capable models become available.

OpenAI Reports Novel Linux Exploitation Techniques

OpenAI also examined a sample of 166 exploits produced by its agents.

The company says that, to the best of its knowledge, the agents used 10 novel Linux exploitation techniques in the sampled exploits. OpenAI shared these techniques with third-party kernel exploitation experts, who also considered them new.

The techniques included:

• Two approaches involving persistent elastic objects used to spray objects inside a target kernel cache.

• Two page-grooming techniques intended to improve exploit reliability.

• Five data-only techniques for obtaining privilege escalation directly or through an arbitrary write.

• One technique involving arbitrary type confusion.

OpenAI has not published the full technical details of these techniques, citing safety reasons.

The finding suggests that frontier cyber models can do more than identify familiar vulnerable code patterns. In this research, the agents also developed approaches that OpenAI says were not previously known to the experts who reviewed them.

What the Research Reveals About AI-Assisted Security

OpenAI's findings offer several lessons for defenders and software maintainers.

Vulnerability discovery needs validation

The pipeline produced thousands of candidate findings, but not all could be reproduced. Dynamic validation helped separate potential issues from vulnerabilities supported by runtime evidence.

Successful exploitation still requires independent checks

During an early run, the system reported 200 successful LPE exploits. Human review later found that 20 had obtained root privileges through a different zero-day vulnerability than the one assigned.

OpenAI subsequently tightened task constraints and added an independent check to verify that each exploit used its assigned vulnerability.

This demonstrates why validating the result alone is not sufficient. Researchers must also verify the path through which the result was achieved.

Stronger models may need less orchestration

OpenAI also compared how different model generations performed with and without additional exploitation techniques supplied through the agent environment.

For GPT-5.5 Cyber, providing 103 techniques increased the observed success rate across 63 exploitation candidates from 76.2% to 88.9%.

For GPT-5.6 Cyber, the model achieved a 92.1% success rate without the additional technique layer and 93.6% with it. OpenAI concluded that the more capable model could identify and apply relevant techniques more independently, making some of the heavier orchestration less valuable.

Patch generation requires iteration

The research found that AI-generated patches can require several rounds of refinement to address the original vulnerability without introducing other problems. OpenAI recommends using models to review both human-written and AI-generated patches for bypasses, missing variants and other weaknesses.

Testing infrastructure also needs security review

During a separate kernelCTF research run, the prototype identified and exploited a QEMU TCG vulnerability while investigating Linux kernel behavior. OpenAI says the issue had already been fixed upstream but remained in the release build used for the experiment.

The finding highlights that vulnerability research infrastructure can itself contain security weaknesses and should be tested before use.

What OpenAI's Research Means for Software Security

OpenAI's work demonstrates how frontier cyber models can support a broader vulnerability research process, from identifying suspicious code to producing exploits and candidate fixes.

The results also show why automation alone is not enough. Candidate findings need validation, exploits need independent verification and patches require careful review before they are accepted into critical software projects.

For defenders, the research reinforces the importance of keeping systems updated, reviewing previously audited code as model capabilities improve and using layered security measures to limit the impact of local privilege escalation.

OpenAI also warns that, in the near and medium term, a low-privileged account on an unpatched operating system could be functionally equivalent to root access for a well-resourced threat actor. It points to defense-in-depth approaches, including sandboxing and isolation technologies such as Firecracker and gVisor, as ways to limit the potential impact of exploited vulnerabilities.

Through Patch the Planet, OpenAI says it intends to extend this research to other critical software projects and work with maintainers and security partners on vulnerability reporting and remediation.

The broader challenge is not only finding vulnerabilities faster. It is ensuring that discovery, validation, patching and deployment can keep pace with the growing capabilities of automated security research.