OpenAI 11 月 4 日发布了一篇题为 A thousand fewer paths to root 的研究文章，讲他们用一套自动化流水线扫描 Linux 内核的经过。标题里的 948 很抢眼，但文章自己给出的判断更值得你记住：发现漏洞正在变得容易规模化，优先级排序和验证仍是运营上的瓶颈。顺着这条线读下去，你会发现压力正一步步从“找”转移到“证明它是真的”和“把补丁合进去”。
先说清楚几个词。本地提权（local privilege escalation，简称 LPE）指一个已经能在机器上运行程序的普通用户，借助漏洞拿到 root，即系统管理员权限。概念验证（proof of concept，PoC）指能触发漏洞、证明它存在的一小段程序。上游（upstream）指 Linux 内核的官方主线代码树，补丁合入上游后，各发行版才会陆续跟进。
找漏洞已经可以批量完成：12 小时产出 2,308 个候选问题
按 OpenAI 的描述，这条流水线分五段：发现、动态验证、可利用性评估、补丁生成，收尾由人类安全研究员审核。驱动它的是一个尚未发布的网络安全专用模型，扫描在 2026 年 10 月中旬进行，对象是当时的内核主线。
发现阶段又分两步。先由侦察智能体通读代码，挑出低权限用户能触达、又与安全相关的部分，共 5,034 个审计目标、约 280 万行代码，约占整个内核的 7%（内核总量在 4,000 万行以上），这一步花了 3,426 美元。再由分析智能体逐个审读这些目标，12 小时内去重后产出 2,308 个候选问题，花了 316,549 美元。
规模化的趋势在两次扫描的对比里很清楚。今年 7 月下旬，GPT-5.6 Sol 跑同一套流程，找到并利用了 166 个不重复的提权漏洞，花费 513,690 美元；10 月中旬换用更新的模型，数字变成 948 个、1,213,430 美元。再往前，OpenAI 6 月公布 GPT-5.5 Cyber 的成果时，用于验证和报告的提权利用程序是 24 个。
钱和时间主要花在验证与利用上：这几段占了七成以上的 API 花费
候选问题不等于漏洞。OpenAI 让分诊智能体为每个候选写 PoC，放进开启了内核地址检查工具 KASAN（Kernel Address Sanitizer，一种能捕捉内存越界和释放后使用等错误的调试机制）的隔离虚拟机里反复尝试。30 小时内复现了 1,724 个，约占候选的 74.7%。没复现的大多需要更高权限，或者卡在难以触发的竞态条件上，只有 3.1% 属于模型分析错误。
接下来是判断严重程度。初筛智能体把范围缩小到 313 个信息泄露候选和 1,238 个提权候选，随后的利用开发智能体在开启了标准发行版防护（包括 SMEP、SMAP、KASLR 等阻止内核执行或读写用户态内存、随机化内核地址的机制）的虚拟机里动手，得到 291 个信息泄露 PoC 和 1,169 个能拿到 root 的提权利用。OpenAI 又做了变体分析，把这些利用背后的漏洞归并成 948 个不同的补丁，并以此作为不重复提权漏洞的数量。
| 阶段 | 产出 | API 花费 |
|---|---|---|
| 侦察（挑审计目标） | 5,034 个目标，约 280 万行 | 3,426 美元 |
| 分析（找候选） | 2,308 个候选，12 小时 | 316,549 美元 |
| 动态验证 | 复现 1,724 个，30 小时 | 73,330 美元 |
| 初筛 | 313 个泄露候选，1,238 个提权候选 | 44,194 美元 |
| 利用开发 | 291 个泄露 PoC，1,169 个提权利用 | 775,929 美元 |
把表里后三段加起来是 893,453 美元，约占总花费 1,213,430 美元的 73.6%，单是利用开发就占 63.9%；发现两段合计 319,975 美元，约占 26.4%。这些比例是我按文章数字算的，文章没有单独列出补丁生成的费用。OpenAI 自己也说，验证一个真漏洞和验证一个误报花的钱差不多，所以越早剔除误报越省钱。
人工复核的必要性也写在文章里。早期一次运行报告了 200 个成功的提权利用，人工检查后发现其中 20 个是借助另一个零日漏洞拿到的 root，并不是分配给它的那一个。OpenAI 随后加了独立检查，确认每个利用确实用的是指定漏洞。这件事说明，流水线越自动化，“证明结果为什么成立”的工作就越不能省。
“低权限账号约等于 root”有明确前提：内核没打补丁，攻击者已经能登录
OpenAI 文章里有一句很容易被转述成标题的话：在近中期，对资源充足的攻击者来说，拿到一台没有及时打补丁的系统上的低权限账号，在功能上应视同拿到 root。你转述这句话时要带上它的全部条件。
首先，它说的是本地提权，攻击者必须已经能在这台机器上以普通用户身份运行程序，比如已经有一个账号，或者已通过别的漏洞进来；这批漏洞本身不提供远程入侵的入口。其次，前提是系统没有更新到已有的补丁，已经打上修复的内核不在此列。再次，主体是资源充足的攻击者，文中的单个成功的利用平均开发成本是 359 美元，但前提是拥有同等能力的模型和工具链。
测试环境也有边界。OpenAI 说目标虚拟机运行的是一个常用发行版的标准桌面系统，没有刻意削弱防护。在攻击面更小的谷歌 kernelCTF 环境里，结果明显收窄：112 小时、约 32,936 美元，得到 21 个提权利用和 25 个信息泄露 PoC，而且为了兼容新内核，他们去掉了 kernelCTF 的 SLAB_VIRTUAL 防护。作为参照，OpenAI 说 2026 年截至发文时 kernelCTF 一共接受了 26 个确认的零日提权利用。至于按 Pwn2Own 和 TyphoonPWN 历史奖金算出的 1,890 万到 6,630 万美元“估值”，文章自己称之为假设性估算，并不是真实成交。
维护者和其他研究者已在快速修补：10 天里 61 个提权漏洞已在上游修复，修复来自其他贡献者
扫描和人工分析持续了 10 天。OpenAI 说，到结束时有 61 个提权漏洞已在上游修复，43 个有了处于暂存阶段的补丁，299 个正在公开报告和讨论。OpenAI 明确说，这 100 多个已修复或已有暂存补丁的提权漏洞来自其他贡献者，也就是同一批问题有别人在同时发现并修补，这和内核文档说 AI 找到的漏洞常在多个研究者那里同一天冒出来是吻合的。OpenAI 还说已按内核社区的建议，先发出数百份针对严重漏洞的报告和补丁，其余部分与 Patch the Planet 计划的合作方分批提交，具体发出多少、被接受多少，文章没有给数字。
内核这边的官方规则对这种局面有直接规定。docs.kernel.org 上的安全漏洞报告文档有“负责任地用 AI 找漏洞”一节，开头就说提交给安全团队的报告里有相当一部分来自 AI 辅助的代码审查，这给维护者造成了过载，有时质量太差只能忽略。文档要求报告简短、纯文本、只陈述可验证的影响，必须附上经过测试的复现程序，并请工具先提出并测试修复补丁，补丁要带上标明引入问题那次提交的 Fixes 标签。
更直接影响披露节奏的是这条：用 AI 辅助发现的漏洞，报告者必须当作已公开处理，因为安全团队的经验是这类漏洞会在多个研究者那里同时冒出来，常常是同一天。复现程序不要公开，维护者需要时会私下索取。文档还写明，安全团队对未公开漏洞的修复，可以应报告方或受影响方请求推迟发布，期限从发布流程启动时算起不超过 7 个自然日；如果各方同意漏洞的严重程度需要更多时间，特殊情况下可延长，但总共不超过 14 个自然日。推迟的正当理由只有一个，就是为质量测试和需要协调发布的大规模部署留出时间，已公开的漏洞修复则立即发布。
所以，维护者面对的不是“漏洞太难找”，而是成批涌来、彼此重复、需要逐个确认和审阅补丁的报告。OpenAI 在文章里给的建议也指向这一点：自动分诊应考虑快速修补的节奏，把发现重新对照当前代码验证，避免提交重复或过时的报告。至于内核安全团队或 security@kernel.org 是否针对 OpenAI 这批报告发表过声明、处理队列积压到什么程度，我没有找到官方材料，目前未知。
对你来说，决定安全的是更新速度：先补丁，再隔离
把这些放在一起，判断就清楚了。找漏洞的边际成本正在快速下降，OpenAI 用两次扫描证明更强的模型能在同一份代码里找到更多问题；真正限制安全改善速度的，是验证结果是否可信、补丁是否正确，以及维护者能否消化这些补丁。OpenAI 自己也承认，模型直接写的补丁有时代码过多、偏离代码风格，或漏掉同类变体，需要人指导迭代。
如果你管理 Linux 服务器或多用户系统，眼下能做的事很具体。把内核更新周期缩短，因为 10 天里就有几十个修复进入上游，旧内核上的普通账号风险正在上升。减少不必要的本地账号和能在机器上执行代码的入口，这批漏洞都需要先拿到本地执行权限。对跑不可信代码的场景，按 OpenAI 的建议加一层沙箱或隔离，比如 Firecracker 和 gVisor，限制被攻破后的影响范围。找漏洞的工具会越来越多，你能控制的是补丁多快落到自己的机器上。