OpenAI公布基于尚未发布的网络安全模型对Linux内核的自动化安全研究：在分析2308项候选发现后，最终确认并去重为948项独特本地提权漏洞，实验端到端API费用约121万美元。公司强调这些结果需人工复核、并通过维护者推动修复，补丁合入和部署仍是独立的后续流程。
OpenAI在2026年11月4日公布一项Linux内核安全研究：公司称，一套由尚未推出的网络安全模型驱动的研究流水线，分析了2308项候选发现，动态复现1724项漏洞，并在进一步验证、变体分析和补丁去重后，按948份不同补丁统计出948项独特的本地提权漏洞。公司披露，这轮实验的端到端API费用为1,213,430美元，约121万美元。研究原文同时强调，结果仍需人工复核，并通过维护者推动修复。
这些数字不是“948台设备遭到入侵”，也不意味着948项漏洞已经全部修好。本地提权指的是：攻击者已经能够以低权限用户身份在目标系统运行代码，再利用漏洞取得root最高权限；它不能直接等同于从互联网远程攻陷任意Linux设备。OpenAI展示的是受控研究环境中的利用验证，而非真实世界攻击规模。
948项结果，如何从2308项候选中筛出来
这项实验的重点不只是让模型阅读源码。按照OpenAI的说明，流水线包含漏洞发现、动态验证、可利用性评估、补丁生成和人工复核五个阶段，最终交付根因分析、最小崩溃概念验证、候选补丁及完整利用程序，供研究人员判断严重程度并向维护者报告。
第一步是缩小审计范围。侦察智能体根据低权限用户能否触及相关代码、代码是否具有安全意义等条件，选出5034个审计目标，覆盖约280万行代码，约占整个内核代码库的7%。随后，分析智能体在12小时内产出去重后的2308项候选发现。这里的7%是本轮选出的审计代码范围，不是整个内核只有7%的代码可能存在安全问题。
候选报告并不等于真实漏洞。OpenAI随后让分流智能体在启用内核地址消毒器KASAN的隔离虚拟机中，生成并反复调整测试程序，检查能否得到可测量的内存破坏证据。该阶段在30小时内复现1724项漏洞，约为候选数量的74.7%。其余发现并不全部属于误报：有些需要更高权限，有些涉及难以触发的竞态条件，或未能在时间预算内完成验证。
在可利用性评估中，智能体使用开启SMEP、SMAP、KASLR等防护的虚拟机，避免通过关闭常见保护来夸大结果。OpenAI称，系统生成了291个信息泄露概念验证和1169个可工作的本地提权利用程序；经过变体分析，为这些提权利用背后的漏洞开发出948份不同补丁，并以此作为独特本地提权漏洞的统计口径。因此，1169个利用程序与948项漏洞不是两个可以相加的数字。
候选补丁，不等于用户已经获得修复
这轮扫描针对的是2026年10月中旬当时最新的Linux内核代码。OpenAI称，自动扫描和人工分析在10天后结束时，其中61项本地提权漏洞已在上游修补，43项已有待合入补丁，299项正在公开报告和讨论。上述数字描述的是研究结束时的状态，不能当作11月4日之后持续更新的修复清单，也不能据此把全部948项称为仍未公开的零日漏洞。
公司表示，已按Linux内核社区建议，优先发出数百份关键漏洞报告和补丁，再与合作伙伴逐步处理其余发现。这不同于宣布948份补丁全部通过审核、合入内核或进入各发行版更新。补丁生成、维护者接受、上游合并和下游部署，是彼此不同的环节。
这一安排延续了OpenAI于6月22日公布的Patch the Planet计划。该计划与Trail of Bits等机构合作，强调在报告交给开源维护者之前，由安全工程师复现证据、剔除重复项、重估严重性，并协助补丁开发与测试。AIFlux此前对这一开源维护者支持计划的介绍也指出，其目标不是单纯增加漏洞报告，而是减轻维护者处理报告和修复问题的负担。
成本下降的潜力，与不能直接比较的数字
OpenAI将这次研究与7月下旬的一轮实验作了比较：此前GPT‑5.6 Sol找到并利用166项独特本地提权漏洞，端到端API费用为513,690美元；10月采用更新网络安全模型的一轮，则得到948项结果，费用为1,213,430美元。
这些数据支持OpenAI关于“更强模型可能找到更多漏洞”的观察，但并非严格控制变量的同一代码快照对照实验。公司明确，两轮都扫描各自当时最新的Linux内核主分支；因此，目标代码随时间发生了变化，不能把全部差异直接归因于模型升级。原文也将本轮核心模型称为“即将推出的网络安全模型”，这不是一次面向公众的模型正式上线公告。
成本同样需要限定口径。公开金额是该研究配置和工作流下的API费用，并不是包含人工审查、基础设施以及后续维护工作的完整账单。OpenAI称，本次研究首先关注方法和能力测量，而非成本优化，认为改进智能体运行框架可能降低开支；这是公司的预期，不是已经兑现的成本降幅。
原文还把潜在漏洞赏金与研究费用比较，但这种估值并不等于实际收入。在另一轮参照Google kernelCTF环境的测试中，OpenAI报告获得21个本地提权利用程序，同时说明因兼容性问题移除了SLAB_VIRTUAL防护。相比之下，Google公开规则列出的正式加固目标启用了该防护，并对漏洞新颖性、稳定性、提交竞争和人工审核设有限制。因此，这轮结果不能被写成21项已通过kernelCTF验收的成果，相关赏金也不能被写成已领取。
拿到root，还不意味着证明了正确的问题
研究中最值得注意的一项经验，来自自动化系统如何判断“成功”。OpenAI披露，在早期一次运行中，系统报告了200个成功的本地提权利用程序；人工复核发现，其中20个虽然拿到了root权限，却利用了与任务指定目标不同的另一项零日漏洞。团队随后收紧约束，并加入独立检查，确认最终利用程序确实使用了被分配的漏洞。
这一案例说明，安全研究不能只看结果是否达成，还要核对达成结果的路径。一次成功提权，若不能证明它来自报告中的根因，就不足以确认原报告的严重性，也不足以证明针对该报告生成的补丁解决了问题。
OpenAI还承认，最初直接生成的补丁有时虽然能阻止概念验证程序，却会引入不必要代码、潜在性能取舍，或遗漏相关漏洞变体。公司称，通过补充指令和迭代流程改善了补丁质量；但这仍是研发中的能力，不能替代维护者对正确性、完整性和长期维护成本的判断。
研究环境自身也可能改变结论。在kernelCTF相关实验中，智能体发现并利用了一项QEMU TCG漏洞；人工分析后，团队确认问题在上游QEMU已经修复，但实验所用发布构建尚未包含修复。这意味着，测试中出现的异常并不一定来自被审计的Linux代码，也可能来自承载实验的虚拟化基础设施。
真正的防御收益，取决于修复能否跟上
OpenAI这次披露展示的变化，是AI安全研究从生成可疑代码报告，向批量复现、验证影响和提供修复材料推进。但这些数量、成本和质量判断主要来自OpenAI自身，不能视为对全部发现完成独立审计的结论。
对维护者而言，价值不在收到更多报告，而在收到去重、可复现、严重性清楚且补丁质量足够的材料。OpenAI也建议，在提交之前重新对照最新代码验证结果，避免快速修补周期让报告变得重复或过时。对系统运营者而言，研究成果是否转化为实际保护，最终仍取决于相应修复是否进入其使用的内核、发行版和运行环境，而不是一份候选补丁是否已经由模型生成。