A thousand fewer paths to root

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.Why the Linux kernelThe 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.Cost analysisThe 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.The vulnerability research pipelineOur 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.Vulnerability discoveryNot 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 agentsScout 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.Analyst agentsNext, 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.Vulnerability validationA 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, so we were impressed by the accuracy of the analyst agents and the effectiveness of the triage agents in autonomously creating working proofs of concept for almost three quarters of the candidate findings.Most remaining findings either required elevated privileges or failed to reproduce within the time budget because of difficult race conditions, specific trigger conditions (e.g., a required allocation failure at a specific line), or time-consuming validation (e.g., refcount wraparound). Only 3.1% reflected incorrect analysis by the model, where the reported vulnerability assumed an impossible condition.The validation stage cost $73,330 in API credits in total. We observed that in our validation pipeline, which needed to generate a proof-of-concept to confirm if a candidate is a real vulnerability, this process was more expensive than making a recommendation based only on static analysis, and the costs of attempting to validate a true positive and false positive were similar. Thus removing false positives earlier in the pipeline makes the process meaningfully more cost-efficient.Exploitability assessmentValidation establishes that a vulnerability is real, but not how urgently it should be addressed.

A vulnerability that could enable local privilege escalation, for example, warrants greater priority than one that could only cause a local denial of service. With 1,724 validated vulnerabilities, the next task was to identify the findings with the greatest potential security impact.An initial screening agent reviewed each report, crash log, and relevant source code statically.