Local privilege escalation vulnerabilities in Linux

We've developed an autonomous vulnerability discovery, exploitation, and patching pipeline. In one run with our cyber model, it validated and generated patches for 948 local privilege escalation vulnerabilities in Linux at an API cost of $1.2 million.

Share

Why the Linux kernelWhy the Linux kernel

Cost analysis

The vulnerability research pipelineVulnerability discoveryScout agents

Analyst agents

Vulnerability validation

Exploitability assessment

Patch generation

FindingsMaintainers are moving quickly to patch vulnerabilities

Stronger models find more vulnerabilities

Novel exploitation techniques

What defenders can learn from exploit costs

Using the wrong 0-day

More capable models can require lighter orchestration

Iteration improves patch generation

Vulnerabilities in testing infrastructure

Conclusion

Why the Linux kernel

Cost analysis

The vulnerability research pipelineVulnerability discoveryScout agents

Analyst agents

Vulnerability validation

Exploitability assessment

Patch generation

FindingsMaintainers are moving quickly to patch vulnerabilities

Stronger models find more vulnerabilities

Novel exploitation techniques

What defenders can learn from exploit costs

Using the wrong 0-day

More capable models can require lighter orchestration

Iteration improves patch generation

Vulnerabilities in testing infrastructure

Conclusion

Security research that once required a separate, sustained investigation for each finding can increasingly be run as a systematic process. This document explores one of our efforts in this area.

Vulnerability discovery is becoming easier to scale, but prioritization and validation remain operational bottlenecks. We built a prototype to look for security flaws in the Linux kernel inside a controlled research environment. Our prototype identified and analyzed 2,308 candidate Linux kernel findings, dynamically reproduced 1,724 vulnerabilities, and produced 948 local privilege escalation (LPE) exploits that could allow an unprivileged local user to gain root access.

We used this evidence to prioritize vulnerabilities for reporting and developed candidate patches for maintainer review. Following guidance from the Linux kernel community, we began with critical vulnerabilities and are working with Patch the Planet partners on further reports and patches.

In June, as part of our Patch the Planet initiative, we shared that GPT‑5.5 Cyber had identified Linux kernel vulnerabilities and developed 24 local privilege escalation exploits to validate and report them. We expanded that work into a pipeline, powered by an upcoming cyber model, covering vulnerability discovery, dynamic validation, exploitability assessment, and patch generation. When it finished, human researchers reviewed the outputs and reported found vulnerabilities alongside patches.

At a high level, our pipeline works as follows: first it identifies security-relevant parts of the Linux kernel, statically scans those audit targets for candidate findings, dynamically reproduces those findings in an isolated environment, creates a proof-of-concept (PoC) exploit to demonstrate exploitability, generates patches, and finally a human security researcher reviews the results.

The output of the pipeline includes a root cause analysis, a minimal crashing proof-of-concept, a candidate patch, and a full exploit to assist human researchers in assessing the severity of the vulnerability and upstreaming the fixes.

In a run in mid-October 2026, our pipeline using an upcoming cyber model dynamically reproduced 1,724 vulnerabilities and generated PoCs for 291 information leak vulnerabilities and 948 working local privilege escalation (LPE) exploits for a commonly used Linux distribution. The total run cost $1,213,430 in API credits, or $1,279 per LPE exploit.

The target virtual machines ran a stock desktop operating system, not a weakened target, under the same threat model used by cybersecurity competitions (e.g. Pwn2Own⁠(opens in a new window), TyphoonPWN⁠(opens in a new window)). Historically, Pwn2Own and TyphoonPWN offered a $20,000 and $70,000 bug bounty for Linux kernel LPE exploits. Applying those historical bounty amounts to the 948 exploits produces a hypothetical valuation of $18.9M—$66.3M, approximately 16x to 55x our pipeline’s cost.

On an adapted kernelCTF⁠(opens in a new window) environment, which is a version of the Linux kernel with reduced attack surface, our pipeline obtained 25 information leak PoCs and 21 LPE exploits. For comparison, 26 confirmed 0-day LPE exploits have been accepted by kernelCTF in 2026 at the time of writing.

The campaign cost roughly $32,936 in API credits. If the 21 vulnerabilities were accepted by the program, it would lead to around a $1.5M bounty award, ~45x the scanning cost.

To the best of our knowledge, the agents in this pipeline discovered and used at least 10 novel Linux exploitation techniques.

The Linux maintainers and security community are working hard to rapidly discover and fix vulnerabilities. Within 10 days while the scan was running, we observed over 100 Linux LPEs had been patched or had staging patches from other contributors, with ~300 more being publicly discussed.

Given the rate of vulnerability discovery by frontier models, we believe automated patch generation is essential to secure software at the pace required, and to limit the exploitation window. With human expert-guided iteration, we believe AI-generated patches can be functionally correct, aligned with existing coding styles, and robust to attack variants. This is an important area for further research.

More capable models are able to discover new vulnerabilities in existing code, often including ones that have been around longer and are more complex to identify. Our analysis pipeline using the newer cyber model in mid-October discovered >5x more novel LPEs than a GPT‑5.6 Sol run in July, despite three months of hardening between the scans.

Large, complex software projects likely require multiple rounds of scanning and fixing vulnerabilities to “bottom out” latent bugs. Ideally this process is repeated with each subsequent generation of frontier models. This applies to both proprietary and open source software.

For the near and medium term, 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. Defense in depth, using sandboxes and isolation approaches like Firecracker and gVisor are important for limiting the blast radius of exploited vulnerabilities.

Within the next few years, we believe that if there are vulnerabilities in a given software project, frontier models will likely be able to discover them and even less capable models may be able to develop exploits once disclosed. In a world of no unknown vulnerabilities, it will be critical to build and maintain high assurance software, especially core software such as operating systems, browsers, image parsing libraries, the TCP/IP stack, and more. Investing in training models to write secure code by default, minimizing attack surface by removing unnecessary features, and formal verification are promising areas of future research to effectively scale software security, in addition to finding and fixing existing vulnerabilities.

Why the Linux kernel

The Linux kernel underpins Android devices, cloud infrastructure, supercomputers, and other systems used by billions of people. With more than 40 million lines of code, the kernel exposes a broad attack surface through system calls, networking, filesystems, and device drivers. We chose Linux to study how effectively frontier models could find vulnerabilities and demonstrate their security impact in a codebase of this scale and importance.

The initial vulnerability discovery stage produced thousands of candidate findings, too many for security researchers to manually review and triage. The operational challenge of our vulnerability discovery pipeline was not discovery, but determining which findings could be reproduced, what security boundary they crossed, and which warranted the earliest maintainer attention.

The mission of OpenAI’s Cyber team is to help secure the software the world relies on. We report API costs for each stage to help researchers assess the resources needed to reproduce and extend this work. These costs reflect the models, target configurations, and workflow used in this evaluation. Our broader goal is to help defenders find and fix vulnerabilities, reducing the opportunities available to attackers and raising the cost for them to exploit software.

Finally, note that we focused on methodology and measuring model capability in this research, not cost. We expect that sufficient harness engineering could meaningfully reduce the cost at each stage; thus, the costs we report are more an upper bound.

Our vulnerability research prototype is a pipeline of five stages, which uses an upcoming cyber model at its core:

Vulnerability discovery: Agents identify security-relevant parts of the codebase and scan them for candidate findings.

Dynamic validation: Agents attempt to reproduce each candidate in an isolated environment and preserve runtime evidence. This step outputs the reproduced and validated vulnerabilities.

Exploitability assessment: Agents test whether validated vulnerabilities could enable information disclosure or local privilege escalation.

Patch generation: Agents generate patches that address each identified vulnerability.

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

At the end of the pipeline, the system bundles a root cause analysis, a minimal crashing proof-of-concept, a candidate patch, and a full exploit to assist human researchers in assessing the severity of the vulnerability and upstreaming the fixes.

Not every line of code in the Linux kernel is security-relevant. Our pipeline used a team of Scout agents to identify high-value audit targets, which were then passed to Analyst agents for vulnerability scanning.

Scout agents

Scout agents read through each folder and file and determine what targets to audit based on their reachability (reachable by low-privileged users) and security relevance.

This stage identified 5,034 audit targets, about 2.8 million lines of code, which is roughly 7% of the whole Linux kernel code base, significantly reducing the cost of the security audit when compared to a full codebase analysis. This step cost $3,426 in API credits.

Next, analyst agents analyzed each audit target and produced candidate findings using a workflow similar to that of the Codex Security plugin⁠(opens in a new window). At a high level, the analyst agents read the assigned audit target’s code to understand how it works, identify its threat model, and look for vulnerabilities in it.

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

A candidate finding is not the same as a validated vulnerability. At this scale, manually investigating every report is impractical for our research team.

We therefore focused on validating findings that a) were reachable by a low-privileged user, b) required no special capabilities, and c) produced measurable evidence of memory corruption.

For each candidate, a triage agent generated a proof of concept and ran it in an isolated virtual machine running a Linux kernel with Kernel Address Sanitizer (KASAN). The agent observed both the program output and system console, then iteratively refined the proof of concept until it reproduced the reported behavior or exhausted the potential ways of triggering it.

Within 30 hours, our system reproduced 1724 vulnerabilities, ~74.7% of the 2,308 candidate findings. Static code review alone can be prone to false positives, s