OpenAI 用 Agent 找出 948 个内核提权漏洞

核心要点（TL;DR）：OpenAI 的 AI Agent 团队花费约 121 万美元 API 额度，将 Linux 内核 5,034 个审计目标转化为 948 个独立本地提权（LPE）漏洞利用，再交人类研究员复核。你可以在自有代码库复刻这套结构：让不同职责的 Agent 分阶段侦察入口、分析源码、在隔离环境验证每条发现并起草补丁，最后由人审批合并。

2026 年 11 月 4 日，OpenAI 发表了《少了一千条通往 root 的路径》（A thousand fewer paths to root）。对研发团队真正有价值的经验是背后的协作机制：多个专职 Agent 按阶段接力，每一棒都移交可核验的证据，并由人类把守最后一关。

这套工作流可直接迁移到业务服务。OpenAI 指出，按公开漏洞悬赏金计算，这条流水线已是“净盈利”的。攻击者同样会算这笔账，防守方现在就该行动了。

OpenAI 的 AI Agent 团队到底发现了什么

2026 年 10 月中旬，OpenAI 使用一款安全专用模型（cyber model），在隔离虚拟机中对最新版 Linux 内核跑了一轮完整流水线。

阶段	产出结果	API 成本
侦察（Scout）	筛出 5,034 个目标，约 280 万行代码（占内核约 7%）	$3,426
分析（Analyze）	2,308 个候选漏洞发现	$316,549
动态验证（Validate）	成功复现 1,724 个（约 74.7%）	$73,330
可利用性评估（Assess exploitability）	948 个独立 LPE 利用程序、291 个信息泄露 PoC	$820,123
合计		$1,213,430

OpenAI 称这笔开销“更接近成本上限”，因为实验旨在测试能力上限而非压缩成本。同时需明确三个边界：

均为本地提权（LPE）漏洞。攻击者须先拿到目标机器的本地低权限访问权，不能直接跨网远程攻破服务器。
部分补丁仍在合入中。10 天扫描结束时，已有 61 个 LPE 在上游修补、43 个有暂存补丁（staging patches）、299 个在公开讨论中，其余正通过 Patch the Planet 分批报送。
原文未提及这些漏洞已出现野利用。

但 OpenAI 提醒，在未打齐补丁的系统上，“对于资源充足的威胁行为者而言，低权限账号在功能上应当被视同于拥有 root 权限”。请及时更新补丁，并用 Firecracker、gVisor 等强隔离方案限制爆炸半径。

AI Agent 安全工作流的五个阶段

OpenAI 将代码审计拆成五个阶段，逐级收窄范围并移交客观证据：

发现（Discovery）。侦察 Agent 挑选可达目标；分析 Agent 阅读源码、建威胁模型并上报候选漏洞。
动态验证（Dynamic validation）。分流 Agent 编写 PoC，在开启 KASAN 的隔离虚拟机中迭代运行，直到复现崩溃或耗尽尝试次数。
可利用性评估（Exploitability assessment）。初筛 Agent 过滤缺乏可行路径的发现，再由 ExploitDev Agent 深度测试剩余项。
补丁生成（Patch generation）。Agent 遵循代码风格起草修复补丁，并排查同类变体。
人工审查（Human review）。报送前由人类研究员复核利用程序、补丁与严重等级。

AI Agent 安全工作流五阶段示意图：从侦察分析、动态验证、可利用性评估、补丁生成到最终人工审查，每阶段通过证据交接

怎么把这五个阶段映射到你自己的仓库

请仅在有权测试的自有代码库上运行此流程。业务团队可直接省掉“编写攻击利用程序”一步：只要写出能稳定触发缺陷的失败测试，就足以证明问题存在，无需构造攻击载荷。

OpenAI 阶段	你的业务仓库版本	阶段产出物
侦察（Scout）	列出低权限可达入口：路由、Webhook、上传、解析器、队列	待审计清单
分析（Analyst）	每次只看一个目标：读源码、写威胁模型、上报可疑缺陷	候选发现列表
验证（Validate）	在一次性隔离环境写出最小可复现的失败测试	测试文件 + 日志
评估（Assess）	按越过的信任边界评估影响面	严重等级与依据
补丁（Patch）	连同回归测试起草修复 Pull Request	草稿 PR
人工（Human）	代码审查，决定合并补丁或关闭报告	合入或关闭记录

先收窄范围非常划算：OpenAI 侦察阶段仅花 3,426 美元就把范围收敛到内核代码的 7%。你可以先从一个核心服务的公开入口开始，单条验证任务写明目标入口、隔离环境、所需证据（测试、日志与调用路径）及停止条件即可。

从 OpenAI 安全流水线提炼的五条实操经验

不仅要验证结果，更要验证触发路径

早期测试中，OpenAI 利用阶段上报了 200 个成功案例，复核却发现其中 20 个是通过另一个非本次指定的 0-day 拿到了 root 权限。为此 OpenAI 增加了独立核验，检查利用程序是否确实触发了目标漏洞点。在业务代码里，同样应安排一个不参与写测试的核查 Agent，确认测试失败确实来自报告指出的代码路径，而非缺少前置测试数据（fixture）。

尽早过滤误报，因为验证误报同样烧钱

OpenAI 发现，动态验证真漏洞与误报（false positive）的成本几乎相同。因此，只把“低权限可达、无需特殊权限、能产生可观测证据”的候选点送入验证，并在建单前对照最新主干重查。你也可以设定“无需管理员角色即可调用”等准入条件，不满足的直接附原因关闭。

在运行开始前先定好“放弃规则”

最烧钱的是失败尝试：在 LPE 候选点上，69 次失败尝试平均每条耗资 3,922 美元，而 1,169 次成功尝试平均仅 360 美元；约 6% 的失败尝试吃掉了该阶段 69.1 万美元总开销的近 39%。OpenAI 的解法是设放弃条件（如连续一小时无实质进展即停手）。在 HiFox 中，单任务最大运行时长可以在 Agent 的运行设置中配置；指令里仍要写明“连续两次尝试无新证据即停止”。

随着模型升级，及时给编排脚手架做减法

OpenAI 曾为 GPT-5.5 Cyber 搭建含 103 种利用技巧的编排层，把成功率从 76.2% 提至 88.9%；换用 GPT-5.6 Cyber 后仅带来 1.5 个百分点提升，团队便将其移除。每次模型升级都应重测脚手架，并定期重扫旧代码：OpenAI 10 月发现的新型 LPE 数量是 7 月使用 GPT-5.6 Sol 时的 5 倍以上，哪怕期间内核已多加固了三个月。

任何代码上线前都必须保留人工审查

Agent 初版补丁有时改动过大或遗漏变体。OpenAI 建议先做对抗性审查（adversarial review），让审查 Agent 尝试绕过补丁，再把正反证据交给人类拍板。若人审已成为瓶颈，可参阅《AI时代人审才是瓶颈？给并行 Agent 设计一套能扩展的审查流程》。

怎么在 HiFox 中用任务跑通这套安全工作流

在 HiFox 中，任务（Task）是核心工作单元。可按五步搭起安全审计流水线：

创建专属任务类型。每个任务类型都有一套有序状态。可新建「安全发现」类型，状态设为：候选、已复现、已起草补丁、审查中、已关闭（状态库共享，请新增专用状态而非改名通用状态）。
组建安全小队（Crew）。小队是由一名队长 Agent 协调、由人和多个 Agent 组成的可复用协作单元。把侦察、分析、核查和补丁 Agent 加入同一小队，由队长率先启动并按分工点名成员接力处理。
隔离每次运行。将工作目录设为创建临时目录，让每个任务在独立的 Git worktree 中运行（细节见《多个 Agent 并行时，为什么不会改到同一份文件》与《怎么监控并行运行的编程 Agent》）。因核查 Agent 需独立环境，请不要开启小队的「同一电脑上的小队成员共用任务目录」选项，保持默认的隔离方式。
用自动化串联交接。配置一条带「任务状态变化」触发器的自动化，当任务移动到「已复现」状态时自动触发补丁 Agent，并在指令中写清目标空间、任务类型与输出要求。由任务状态变化触发的运行会归属到该任务的对话记录中，便于在同一条任务里追踪。
关联 Pull Request。连接 GitHub 集成后，分支名、PR 标题或描述中的任务编号会自动关联 PR。合并 PR 不会自动改变任务状态，由人工审阅者确认后关闭任务。

注意 Git worktree 不是安全沙箱，务必在无生产密钥的隔离容器中运行复现测试。HiFox 负责任务编排与证据留存；Claude Code、Codex 等负责执行，Token 消耗仍走你已有的订阅或密钥。小型仓库直接把单个 Agent 指派给任务即可，无需动用小队；需要队长按序调度多个角色并把结果汇总回同一条任务时，再启用小队。