一千条更少的根路
我们开发了一个自主的脆弱性发现，开发，和补丁管道。 在使用我们的网络模型的一次运行中，它验证并生成了Linux948个地方特权升级弱点的补丁，花费120万美元的API.
安全研究一旦要求对每一项调查结果进行单独、持续调查，就可越来越多地作为一个系统的过程进行。 这份文件探讨了我们在这一领域的努力之一。
脆弱性的发现越来越容易扩大，但确定优先次序和鉴定仍然是业务瓶颈。 我们建造了一个原型，在受控制的研究环境中寻找Linux内核的安全缺陷。 我们的原型确定并分析了2 308个候选的Linux内核调查结果，动态地复制了1 724个弱点，并产生了948个地方特权升级(LPE)的利用，可以让一个没有特权的当地用户获得根基接入。
我们利用这些证据优先处理报告的脆弱性，并开发了供维护者审查的候选补丁。 在Linux内核社区的指导下，我们首先从严重的脆弱性着手，并正在与Patch the Path the Planet伙伴合作，编写进一步的报告和补丁。
6月，作为《星球补丁》倡议的一部分，我们分享说，GPT‐5.5 Cyber查明了Linux内核弱点，并开发了24个地方特权升级，以验证和报告这些弱点。 我们把这项工作扩展为一个管道，由即将到来的网络模型提供动力，包括脆弱性发现、动态验证、可开发性评估和补丁生成。 报告完成后，人类研究人员审查了产出，并报告发现除补丁之外还有弱点。
目录
方法
- 在高层次上，我们的管道工程如下：首先确定Linux内核中与安全有关的部分，静态扫描这些审计对象以获取候选结果，在孤立的环境中动态复制这些结果，建立概念证明(PoC)以证明可开发性，产生补丁，最后由人的安全研究人员审查结果。
- 输油管的产出包括：根源分析、最低限度的崩溃性概念证明、候选补丁和充分开发，以协助人类研究人员评估脆弱性的严重性和使修复措施上游。
调查结果
- 在2026年10月中旬的一次运行中，我们使用即将到来的网络模型的管道动态地复制了1 724个弱点，并为291个信息泄露弱点和948个正在工作的当地特权升级(LPE)开发了常用的Linux分销。 运行费用共计1 213 430美元(API信贷)，或每LPE开采1 279美元。
- 目标虚拟机在网络安全竞赛(如Pwn2Own(在新窗口打开),TyponPWN(在新窗口打开))使用的相同威胁模型下运行一个股票桌面操作系统，而不是削弱的目标。 历史上，Pwn2Own和TyponPWN为Linux内核LPE开发提供2万美元和7万美元bug赏金。 将这些历史赏金应用于948项开采，产生了1,890万美元 -- -- 663万美元这一假设价值，大约16至55美元我们的管道成本。
- 在经过改造的内核CTF(在新窗口打开)环境中，这是Linux内核的版本，攻击表面减少，我们的管道获得了25个信息泄露PoC和21个LPE开发。 作为比较，在撰写本报告时，内核工作队在2026年接受了26项确认的零天LPE开发。
- 运动花费了大约32 936美元的API信贷。 如果这21种弱点被节目所接受，它将导致大约1.5M的赏金奖，~45x的扫描成本。
- 据我们所知，在这个输油管中agents发现了至少十种新型的Linux开发技术。
反思
- Linux维护者和安全界正在努力迅速发现和解决脆弱性。 在扫描运行的10天内，我们观察到超过100个Linux LPE被补丁或有来自其他贡献者的中继补丁，还有~300个被公开讨论。
- 鉴于前沿模型发现脆弱性的速度，我们认为自动补丁生成对于按所需速度保护软件和限制开发窗口至关重要。 有了人类专家引导的迭代，我们认为AI生成的补丁在功能上可以正确，与现有的编码风格一致，强力攻击变体。 这是进一步研究的一个重要领域。
- 更有能力的模型能够发现现有守则中的新弱点，其中往往包括时间较长且更复杂的模型。 我们使用更新的网络模型的分析管道在10月中旬发现，比GPT‐5.6 Sol在7月份运行时发现的LPE > 5x更多，尽管在扫描之间进行了三个月的硬化。
- 大型复杂软件项目可能需要多轮扫描和确定“从下到下”潜在错误的脆弱性。 理想的情况是，在以后的每一代前沿模型中都会重复这一过程。 这既适用于专有软件，也适用于开源软件。
- 在近期和中期，在操作系统上访问一个低保账户，但最新的补丁没有更新，这在功能上应等同于资源充足的威胁行为者的根接入。 深度防御，使用沙盒和隔离方法，如鞭炮和gvisor，对于限制被利用的脆弱性的爆炸半径十分重要。
- 在今后几年内，我们认为，如果某一软件项目存在弱点，前沿模型可能能够发现这些弱点，而且一旦披露，能力更差的模型可能能够开发利用。 在一个没有未知弱点的世界中，建设和维护高保证软件，特别是操作系统，浏览器，图像解析库，TCP/IP堆栈等核心软件，将是至关重要的。 投资培训模式以默认方式编写安全代码，通过去除不必要的特性来尽量减少攻击表面，以及正式的核查，是未来研究的有希望的领域，除了发现和固定现有的弱点外，还能够有效地扩大软件的安全范围。
Linux内核支撑着Android设备，云基础设施，超级计算机，以及数十亿人使用的其他系统。 拥有超过4000万行的代码，内核通过系统调用，联网，文件系统，以及设备驱动程序，暴露出广泛的攻击表面。 我们选择了Linux来研究前沿模型如何能够有效地发现弱点，并在这种规模和重要性的代码库中显示其安全影响。
最初的脆弱性发现阶段产生了数千项候选结果，安全研究人员无法手动审查和分解。 我们的脆弱性发现管道的业务挑战不是发现，而是确定哪些调查结果可以复制，哪些安全边界可以跨越，哪些需要尽早得到维护者的注意。
OpenAI网络团队的使命是帮助保障世界所依赖的软件的安全。 我们报告每个阶段的API费用，以帮助研究人员评估复制和扩大这项工作所需的资源。 这些费用反映了本评价所使用的模型、目标配置和工作流程。 我们更广泛的目标是帮助维权者发现和解决脆弱性，减少攻击者的机会，提高他们利用软件的成本。
最后，我们注意到，我们侧重于研究的方法和衡量模型能力，而不是成本。 我们期望，充分的利用工程可以在每一阶段切实降低成本；因此，我们所报告的成本更具上限。
我们的脆弱性研究原型是五个阶段的管道，其核心是使用即将出现的网络模型：
- 脆弱性发现：Agents确定密码库中与安全有关的部分，并进行扫描，以了解候选结果。
- 动态验证：Agents试图在孤立的环境中复制每个候选人并保存运行时间证据。 这一步骤产生了复制和验证的弱点。
- 利用性评估：Agents测试经验证的脆弱性是否能够促成信息披露或当地特权升级。
- 补丁生成：Agents生成补丁，处理每一个已查明的脆弱性。
- 人文审查：安全研究者在向维护者报告之前审查开发、补丁和提议的严重程度。
在输油管的尽头，系统将一个根源分析，一个最小的崩溃性概念证明，一个候选补丁，以及一个充分的利用来帮助人类研究人员评估脆弱性的严重程度和使修复方法上游。
并非Linux内核中的每一行代码都与安全相关。 我们的管道利用一个Scout agents小组来确定高价值的审计目标，然后交给分析员agents进行脆弱性扫描。
Scout agents通过每个文件夹和文件阅读，并根据其可达到性(低保用户可达到)和安全相关性确定审计目标。
这一阶段确定了5,034项审计目标，约280万行代码，约占整个Linux内核代码基数的7%，与完整的代码基数分析相比，安全审计成本大幅降低。 这一步骤花费了API信贷3 426美元。
接下来，分析师agents对每个审计目标进行了分析，并利用类似于Codex安全插件(在新窗口打开)的工作流程得出了候选结果。 在高水平上，分析师agents阅读了指定审计目标的代码，以了解它是如何工作的，识别其威胁模型，并寻找其中的弱点。
在12小时之内，分析师agents在分解后产生了2,308个候选结果。 这一阶段的API信贷费用为316 549美元。
候选人的发现与经核实的脆弱程度不同。 在这个规模上，人工调查每份报告对我们的研究团队来说是不切实际的。
因此，我们侧重于验证以下结论：(a) 低保用户能够达到；(b) 不需要特殊能力；(c) 产生了记忆腐败的可衡量证据。
对于每个候选人，一个三进制的agent生成了一个概念的证明，并在一个单独的虚拟机中运行着Linux内核，使用Kenel地址Sanitizer(KASAN)运行。 agent观察了程序输出和系统控制台，然后迭代地完善了概念的证明，直到它复制了报告的行为或者用尽了触发它的潜在方法。
在30小时内，我们的系统重复了1724个弱点，占2 308个候选人调查结果的74.7%。 仅静态代码审查可能容易出现假阳性，因此我们对分析师agents的准确性以及三分法agents在为近四分之三的候选结果自主创建概念工作证明的有效性印象深刻。
剩余的大多数调查结果要么要求提高特权，要么由于困难的种族条件，具体的触发条件(如特定线上所要求的分配失败)，或耗时的验证(如重新计算包)，未能在时间预算范围内复制。 只有3.1%反映了模型所作的不正确分析，而所报告的脆弱性是不可能发生的。
鉴定阶段总共花费了73 330美元的API信贷。 我们注意到，在我们验证过程中，需要提出概念证明，以确认候选人是否真正脆弱，这一过程比仅仅根据静态分析提出建议更为昂贵，试图验证一个真实的正反正的和虚假的正反正的花费是类似的。 因此，在早期的管道中消除虚假的阳性，使这一过程更具有有意义的成本效益。
瓦尔
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
A thousand fewer paths to root
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.
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.
Summary
Methodology
- 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.
Findings
- 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.
Reflections
- 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.
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 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, 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.
Val
Auto-fetched and translated by AI Atlas. All rights belong to the original author.