文章总结： 本文介绍作者基于开源IronCurtain框架构建的vuln-discovery工作流，证明利用Opus4.6、Sonnet4.6等商业模型和GLM5.1等开放权重模型可自主发现零日漏洞。通过有限状态机编排和分层harness方法，成功复现1998年OpenBSD漏洞并在现代代码库中发现新漏洞，单次审计成本30-150美元。文章强调编排框架可帮助防御方规模化漏洞挖掘，并呼吁安全工程师贡献开源工具。 综合评分： 85 文章分类： 漏洞分析,AI安全,安全工具,安全建设,红队

用任何模型都能挖出零日漏洞

Niels Provos Niels Provos

securitainment

2026年5月4日 17:10 中国香港

在小说阅读器读本章

去阅读

| 原文链接 | 作者 | | — | — | | https://www.provos.org/p/finding-zero-days-with-any-model/ | Niels Provos |

关于 AI 驱动的安全研究,主流叙事认为发现新型漏洞是一项 “前沿” 能力,只属于 Anthropic 最近发布的 Mythos Preview 这类受限访问的模型。近期一批备受关注的报告着力展示了这些先进模型挖掘陈年内存安全漏洞的能力——例如 1998 年 OpenBSD TCP SACK 实现中的那个缺陷——并将这些发现描绘为威胁格局的一次范式转变。

事实并非如此。我的研究表明,这种能力并不只栖身于专有的前沿模型,同样也蕴含在驱动商业模型工作的编排框架 (orchestration harness)之中。为了论证这一点,我基于自己开源的 IronCurtain框架构建了一系列工作流。借助其中专门用于漏洞挖掘的工作流,我不仅复现了上述前沿成果,还利用 Opus 4.6、Sonnet 4.6等商业模型,以及 Z.AI 的 GLM 5.1等开放权重模型,自主在基础软件中发现了全新的零日漏洞。

编排漏洞发现流程

IronCurtain是我设计的一个研究原型,旨在支撑结构化、智能体驱动 (agentic) 的安全研究。该框架通过简洁的 YAML 定义,即可承载以有限状态机 (finite-state machines, FSM)形式组织的任意工作流。为了实现自动化漏洞挖掘,我在该 FSM 之上构建了 vuln-discovery工作流,其核心是一个充当策略路由器的中央 Orchestrator智能体,它会依据一份只追加 (append-only) 的执行日志 (journal)来决定下一步该派出哪个专门的智能体。

这份日志让模型得以维持状态、验证假设并在代码库中游走。Orchestrator自身并不读取目标源代码,而是完全依赖日志推进整轮调查,直到产出最终的漏洞报告。借助这份日志以及其他磁盘上的产物,每个智能体状态都可以从一个全新的上下文窗口开始,再从磁盘中恢复 (rehydrate) 所需信息。话虽如此,这套工作流相当消耗 token。针对中等规模代码库的单次运行,在 Opus或 Sonnet上大约消耗 1000 万个 token,每次调查分别花费 150 美元或 30 美元。在 Z.AI 托管的 GLM 5.1上运行了五次,平均每次约 2700 万个 token,这反映出它需要更多迭代轮次才能得出相同结论。Z.AI 给 GLM 5.1的报价是每 100 万输入 token 1.40 美元(命中缓存为 0.26 美元)、每 100 万输出 token 4.40 美元;因此即便 token 用量更大,单次调查的成本仍与 Sonnet 处于同一区间。至于真正在普通工作站硬件上做本地推理,目前仍停留在愿景阶段而非实证演示——我测试过的一个更小的蒸馏候选模型(Qwen 3.5 蒸馏版)无法跑通该工作流,因此 GLM 5.1始终运行在 Z.AI 的 GPU 上。

复现 1998 年 OpenBSD 漏洞

Anthropic 的 Red Team 把 OpenBSD TCP SACK 实现中一个 27 年前的漏洞,作为其 Mythos 报告的核心成果重点展示。这个漏洞对我而言意义特殊——正是我本人在 1998 年 11 月提交了 OpenBSD 的 TCP SACK 实现,而这个 bug 也随之一并被引入。为了验证开源编排能否复现这种前沿能力,我把 vuln-discovery工作流的一个早期版本指向了这段未打补丁的历史 C 代码。

工作流首先借助一个 Sonnet 4.6分析智能体,梳理出结构化的数据流和调用链。FSM 编排遵循一条简单的原则:静态地提出假设,通过执行来验证,其余一切皆为噪声。在该工作流中,概念验证 (proof-of-concept, PoC) 是一个可执行的 harness,用来触发漏洞、证明可达性并暴露内存破坏,从而提供超出静态分析的经验性证据。

然而,在这次对 FSM harness 的首次测试中,提示词与日志记录都还不足以让整个系统保持在正轨上。由于安全的 IronCurtain容器无法原生地启动 OpenBSD 虚拟机,智能体最终完全退回到静态分析。它识别出了 bug,却未能实际触发,产出了一份缺少概念验证 (PoC) 的报告。

这一局限促使我对工作流做了迭代改进。我也逐渐意识到:初步的假设探索并不需要完整的虚拟机,完全可以通过轻量级的 harness 来完成,例如对单个函数做 fuzzing;只有最终的 PoC 才需要走虚拟机这条路径。

为了完成最后的验证,我直接通过 Claude Code 调用 Opus 4.6。在一些手动引导下,我让模型先借助轻量级 fuzzing 复现了该漏洞。它为目标 C 函数设计了一个独立的高性能 fuzzer,在数秒内便系统性地扫描了输入空间,并最终定位到精确的触发条件:在 43 亿个序列号中,只有差值恰好落在 32 位整数符号边界上的那两个取值,才会触发漏洞。

一旦通过 fuzzing 锁定了参数,我便让模型构建一个基于 QEMU 的驱动,在运行中的虚拟机上进行测试,从而稳定地复现出了内核 panic。

这次 OpenBSD 复现是该工作流的第一次实战测试。本轮初次运行所需的人工干预,直接推动了 FSM 提示词与日志记录方式的改进,并确立了一种构建 harness 的分层方法:单函数隔离 harness、多组件 harness,以及完整的端到端虚拟机验证。如今,工作流会根据建立利用原语 (exploitation primitive) 所需的程度,在这些层级间动态伸缩。完成上述改进之后,工作流在后续的调查中已无需任何人工干预即可运行。

自主漏洞发现与防御能力规模化

一个编排框架的真正价值,在于能否在现代代码库中自主发现 bug。vuln-discovery工作流在四个被广泛使用的开源项目中,挖掘出若干此前未被报告的漏洞和重要 bug——而这些项目都已经历过多年的公开 fuzzing 和专门的安全审查。下面两个案例研究是其中具有代表性的运行结果。由于上游协调、CVE 分配以及安全公告仍在进行中,具体身份和精确的漏洞机制暂不公开。

在分析一个被广泛部署的多媒体框架时,vuln-discovery工作流发现了一个此前未被报告的漏洞。在 Opus 4.6的支持下,该框架识别出了缺陷,并构建出一个多组件 harness 来确认底层的利用原语 (primitive)。要用完整的端到端 harness 验证该缺陷,还需要一些人工指引——受内存约束的复现环境最初掩盖了触发条件。在对 harness 做出优化之后,工作流生成了一个能够稳定触发该漏洞的概念验证,我也将这一发现报告给了上游维护者。这一结果验证了如下思路:由商用模型搭配开源编排框架,即可独立完成漏洞发现。

在完全脱离 Anthropic 生态系统之后,后续的另一次运行将同样的 vuln-discovery工作流指向了另一个基础库。唯一改动的是模型本身:借助一个 LiteLLM 网关,把 Anthropic 的模型标识符重写为指向 Z.AI 的 GLM 5.1(通过一个兼容 Anthropic 协议的端点),而 IronCurtain与 FSM 编排层保持完全不变。

整个发现过程由 GLM 5.1端到端驱动。Orchestrator基于只追加的日志锁定了目标范围,并引导系统去构建分层 harness。该自主工作流隔离出一个内存分配路径上的整数截断 (integer truncation) 缺陷——这一缺陷已经潜伏了 18 年,与上文 OpenBSD SACK 案例 27 年的休眠期遥相呼应。通过对相关算术运算的结构化分析,受编排驱动的模型生成了一个概念验证以及一个经过 sanitizer 验证的 harness,足以确认该漏洞类别的存在。

为了在负责任披露中给出准确的严重性评分,需要进一步确认底层的可利用性原语。我在 Claude Code 中借助 Opus 4.7进行了这次人工引导的手动分析——这是我用于深度技术工作的交互式研究环境,在这种深度的分析任务上也比 GLM 5.1更胜一筹。这项工作演示了一种受控的越界堆读和写原语。由于受影响的库被广泛部署在面向互联网的基础设施中,这个缺陷构成了严重的远程攻击风险。

要确认严重性达到 critical 等级,需要一份可用的利用代码,而这已超出 vuln-discovery工作流面向漏洞发现的范围。当模型拒绝了我最初构建利用代码的请求后,我手动把利用开发流程拆解成一个粒度更细、由 7 步组成的方案,以绕过此次拒绝。模型成功执行了前两步,之后其可接受使用政策 (Acceptable Use Policy, AUP) 的护栏迫使它拒绝继续协作。所幸,第二步已经证明可以通过读取基址指针来绕过地址空间布局随机化 (Address Space Layout Randomization, ASLR),这便已是足以支撑高严重性评估的实证证据。

从这几次运行中可以得出三点观察。其一,生成概念验证 (PoC) 利用代码对防御方而言是必要的。通过静态分析识别出的理论性漏洞不可避免地会产生大量误报,而误报会在分级和人工核实环节大量消耗安全运营团队的时间。可执行的漏洞证据能够迅速排除掉这些耗时的误报,使防御方得以聚焦于已确认的威胁。

其二,虽然开源编排为执行复杂工作流提供了必不可少的脚手架,但底层基础模型的质量依然举足轻重——它决定了编排所能发挥能力的下限,而开放权重模型的结果表明,这一下限如今已经低到足够普通的商品级模型也能跨越。

其三,如今的成本结构更倾向于鼓励频繁、广泛的审计。按照商业 API 的定价,每次针对单个代码库的调查花费在 30 至 150 美元之间(从 Sonnet 到 Opus);在生产规模下,这一成本就决定了一个防御方一年内能够投入审计的库的数量。开放权重模型的托管服务商在更高的 token 用量下,价格区间与 Sonnet 接近;而一旦完成前期投入,在合适硬件上自托管会进一步降低边际成本。

编排是一把双刃剑。现实是,资源充足的对手早已在大规模使用编排化的工作流来追猎零日漏洞。他们可以无视厂商的使用政策,无视合法研究中遭遇的 AUP 摩擦,无视多小时运行中的 API 速率限制,也无视那些只对受限前沿模型开放的精选准入名单。在严重性评估中遇到的 7 步拒绝,正是这种不对称的真实写照:一名进行合法工作的防御者会遭遇阻碍,而一名使用未审查开放权重模型的、资源充足的对手却不会。一个本地托管的开放权重模型,可以彻底拆除这道闸门。这种摩擦反映的是一种真切的责任考量,而不仅仅是规避法律风险:厂商需要在为边缘滥用者带来的能力提升,与对合法研究造成的代价之间做出权衡。这种权衡过去也曾发生过——过去 25 年里的每一个防御工具(Metasploit、nmap、Burp Suite、AFL)都面临过同样的争论,而历史给出的答案,始终是把工具交到防御者手中。在本地模型上,责任直接落在研究者身上,正如这些工具一直以来的惯例。IronCurtain的存在,正是为了弥合这道鸿沟。通过把开源脚手架与本地或商品级开放权重模型结合起来,防御方可以在自动化攻击追上脚步之前,审计代码库并发布补丁。我鼓励安全工程师查看 IronCurtain framework,为编排脚手架贡献力量,并帮助构建自动化防御的基线工具。目前新手入门流程仍在打磨之中,因此尤其欢迎那些能够让安装与使用更简便的贡献。

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：securitainment Niels Provos Niels Provos《用任何模型都能挖出零日漏洞》