Evidence at a glance
Five stages, from code selection to patch review
In November 2026, OpenAI described a research pipeline spanning vulnerability discovery, dynamic validation, exploitability assessment, and patch generation. Scout agents first select kernel code worth auditing. Analyst agents scan it for candidate issues and deduplicate the findings. The validation stage tries to reproduce them in an isolated environment and preserves runtime evidence. The pipeline then assesses whether a vulnerability could enable information disclosure or local privilege escalation (LPE), before generating a candidate patch for a security researcher to review and report to maintainers. Each result can include a root-cause analysis, a minimal crashing PoC, a candidate patch, and a full exploit to help researchers assess severity and pursue a fix.
In a run in mid-October, Scout selected 5,034 audit targets covering about 2.8 million lines of code, or roughly 7% of the Linux kernel. The Analyst stage took 12 hours to produce 2,308 deduplicated candidate findings. Dynamic reproduction took 30 hours and reproduced 1,724 vulnerabilities, about 74.7% of the candidates. The report says unreproduced items often involved permission requirements, hard-to-trigger conditions, or complex race conditions; about 3.1% were classified as model analysis errors.
The reported yield: 948 LPEs at about $1,279 each
OpenAI reports that the run produced 948 unique LPE exploits and PoCs for 291 information disclosure vulnerabilities. These are different outcomes and should not be combined. The report also distinguishes working exploits from unique vulnerabilities: after variant analysis, it counts 948 unique LPEs. OpenAI has not published an itemized list, so readers cannot independently check the deduplication case by case.
The run cost $1,213,430 in API credits, or about $1,279 per unique LPE. OpenAI offered a hypothetical comparison with historical bounties: Pwn2Own and TyphoonPWN have offered $20,000 to $70,000 for Linux kernel LPE exploits. Applying those amounts to 948 vulnerabilities gives an estimated $18.9 million to $66.3 million—about 16 to 55 times the pipeline cost. This is not money awarded or a confirmed market valuation. In an adapted kernelCTF environment, the pipeline cost $32,936 and generated 25 information disclosure PoCs and 21 LPEs. If the program accepted those vulnerabilities, the projected bounty would be about $1.5 million, roughly 45 times the scanning cost.
The test setup has limits; the model also found new techniques
OpenAI says the target virtual machines ran stock desktop operating systems and used the same threat model as competitions such as Pwn2Own and TyphoonPWN, rather than deliberately weakened targets. The results still reflect a particular test configuration; they do not establish that the exploits work across every Linux distribution or setup. OpenAI also reports that agents in the pipeline discovered and used at least 10 previously unseen Linux exploitation techniques.
OpenAI compared this run with a July 2026 scan using GPT-5.6 Sol. The newer model found more than five times as many unique LPEs in mid-October, despite three months of kernel hardening between the scans. This is a comparison of two OpenAI runs, not an independent evaluation. It suggests that more capable models may find deeper and more complex flaws in existing code. Large software projects may therefore need repeated rounds of scanning and repair as models improve, rather than relying on a single audit to uncover every latent bug.
Finding flaws is only part of the work; fixes still queue for review
Generating a candidate patch does not mean a vulnerability has been fixed. OpenAI says early patches could be too long, depart from kernel conventions, or miss attack variants. Researchers need to review and refine them before maintainers assess the submissions. Public materials do not say how many of the 948 candidate patches have been accepted upstream, merged, or deployed. OpenAI also notes that its reported API costs reflect the model, target configuration, and workflow used, not a fully optimized minimum cost.
During the 10 days of scanning and analysis, OpenAI observed 61 Linux LPEs that had been fixed, 43 with staging patches, and another 299 being publicly reported or discussed. The report does not say that this entire group was found by its pipeline. The figures illustrate why scaling discovery does not remove the work of validation, prioritization, maintainer review, and deployment—all of which affect the window of risk. Automated patch generation needs to work alongside human review and upstream repair processes. Sandboxes and isolation tools such as Firecracker and gVisor can also help limit the impact if a vulnerability is exploited.