ExploitGym：AI 智能体能把安全漏洞变成真实攻击吗？

核心问题是：智能体能否从“触发漏洞”推进到具有实际安全影响的完整利用？ 作者将漏洞复现与漏洞利用区分开，重点测量未授权代码执行。

• 应用场景：作者认为，利用能力可帮助防御方评估严重性、确定修补优先级和验证缓解措施，也可能降低攻击方开发利用的门槛。
• 现有评测：作者指出，部分基准主要测源码层面的推理；已有包含利用任务的基准则集中于 CTF 或用户态软件，规模至多200项（Table 1）。
• 能力要求：作者强调，利用需要处理运行时内存布局、指令级控制流、受约束输入和多阶段利用链，还可能需要绕过系统防护。
• 提出的基准：ExploitGym 提供真实漏洞、PoV、源码和可重现环境，覆盖用户态、V8 与 Linux kernel，并配置防护开关。
• 成功边界：智能体在受控远程目标上交互，须越过授权范围取得动态 flag，再由智能体裁判检查是否确实利用指定漏洞；取得 flag 本身不算最终成功。

相关研究分为漏洞发现基础设施、自动利用、智能体安全基准和危险能力评测四组。

漏洞发现与档案基础设施

• AFL++、libFuzzer 与领域模糊测试器——通过模糊测试发现漏洞；论文还讨论面向 JavaScript 引擎和操作系统内核的测试器。
• OSS-Fuzz、ClusterFuzz、syzbot、kernelCTF——持续发现、复现或归档漏洞及相关输入、版本和利用材料。作者指出，这些系统原本不是标准化评测基准。

利用技术与自动利用生成

• Stack smashing、ROP、DOP——论文将其列为应对系统缓解措施的利用技术。
• AEG、Mayhem、Gollum、MAZE 等——研究自动利用生成、堆布局操纵等问题。作者概括，这类方法往往对漏洞类别、利用结构或运行环境作较强假设。

智能体网络安全基准

• NYU CTF、Cybench、CVE-Bench、BountyBench——包含利用任务；Table 1 分别列出200、40、40、40项，领域为 CTF 或用户态软件。
• CyberGym、PatchAgent 等——覆盖漏洞复现、补丁生成、安全代码生成等互补能力；Table 1 还列出 BaxBench、SEC-bench、SeCodePLT、SecRepoBench 和 SecureAgentBench。
• 实验对照——主实验比较不同模型与智能体框架在 ExploitGym 上的表现，没有将上述基准作为实验数据集，也没有报告传统自动利用生成器的对照成绩。

危险能力评测

• AgentHarm、WMDP 与 Phuong 等的研究——论文将自身定位为前沿模型潜在危险能力评测的一部分，并强调 ExploitGym 得分更高不意味着模型整体更安全。

作者强调的区别是：把多个软件领域的真实漏洞材料转化为统一任务，结合可配置防护、可重现环境和指定漏洞验证，而不只检查是否获得了安全影响。

ExploitGym 将已有漏洞的触发材料封装成远程利用任务，再分别验证安全影响和利用路径。默认提供漏洞线索，但不提供补丁。

任务输入与交互

• 构建信息：提供源码、构建配置、脚本、编译后的二进制或内核镜像，以及运行配置。
• 漏洞信息：提供 PoV 和文字说明；补丁等信息可独立包含或隐藏，默认隐藏补丁。
• 远程目标：智能体在本地开发，通过限定入口与远程目标多轮交互，并可请求控制器重置目标。组件均封装在容器化环境中（Figure 1）。

三类安全边界

• Userspace：目标以无特权用户运行，编译时关闭 sanitizers；取得 flag 需要在目标进程中实现代码执行。防护开关为 ASLR+PIE 和 stack canary。
• Browser（V8）：使用漏洞版本的独立 d8 shell，移除可直接执行系统操作或读取文件的便利接口，仅保留 PoV 所需入口。防护开关为 ASLR 和 V8 heap sandbox。
• Linux kernel：每次连接进入 QEMU/KVM 虚拟机，智能体进程受 nsjail 约束；flag 位于原始块设备，仅获得用户命名空间内的 UID 0 仍不能读取。配置项为 KASLR 与 user-namespace access（Table 2）。

数据构建与质量控制

• 用户态筛选：从 CyberGym 中获取 OSS-Fuzz 漏洞，并补充 OSV 中非模糊测试发现的漏洞。后者由 Claude Code 配合 Claude Opus 4.6 生成 PoV，再人工核验；重建关闭 sanitizers 的目标后保留520项、161个项目。
• V8 筛选：收集2024年之后提交的 ClusterFuzz 与人工报告，从补丁测试或附件恢复 PoV。构建候选漏洞版本并验证触发情况，从403个候选保留185项。
• 内核筛选：将 kernelCTF 完整利用简化为只触发漏洞的 PoV；对 syzbot 的 x86/x86_64 高严重性内存安全与数据竞争报告去重、复现，最终保留193项。
• 排除捷径：用户态过滤可通过脚本接口直接取得代码执行的入口；V8 缩减 shell 接口。附录 B 给出筛选、防护配置与权限控制细节。

双阶段成功验证

• Flag verification：每个目标生成动态 flag，置于正常授权接口不可访问的位置；提交正确值是必要条件。
• Agent-as-a-judge：裁判读取完整轨迹、任务输入和智能体产物，检查是否利用指定漏洞，排除其他漏洞或已知公开利用造成的捷径。
• 裁判复核流程：通常由 GPT-5.5／Codex CLI 和 Claude Opus 4.6／Claude Code 分别审查，一致时接受，分歧交人工。Anthropic 运行的实验只使用 Claude Code 裁判（第4节脚注）。

主实验比较模型与框架组合的指定漏洞利用成功数，并补充防护、时间预算和裁判验证。

实验设置

• 被测模型与框架：Claude Mythos Preview、Claude Opus 4.6、Claude Opus 4.7、GLM-5.1 配 Claude Code；GPT-5.4、GPT-5.5 配 Codex CLI；Gemini 3.1 Pro 配 Gemini CLI。
• 数据与预算：ExploitGym 共898项：Userspace 520项、V8 185项、kernel 193项。主实验关闭系统防护，每任务一次尝试、墙钟时间上限2小时。
• 模型配置：Table 6 列出7个模型，尽管附录 C 开头写“six models”。推理设置依次为 max、max、xhigh、auto、xhigh、xhigh、high；智能体各限4核 CPU、8 GB 内存。
• 提示与访问：主实验在可信访问项目下关闭部署时内容过滤器，训练形成的拒答仍可能出现。一般使用相同用户提示词，Mythos Preview 额外使用调整指令的 CLAUDE.md；外网访问受白名单限制。
• 指标与判定：Flag 为取得动态 flag；Success 还须通过指定漏洞审查。裁判为 GPT-5.5 和 Claude Opus 4.6，分歧交人工；Anthropic 实验仅用后者。
• 其他统计：Table 3 报告成功子集及全基准的每任务平均估算费用、耗时和 LLM 调用数；没有报告主结果的多次重复统计。

主结果

据 Table 3，全部为关闭系统防护、每任务2小时；U、B、K 分别为 Userspace、V8、kernel，数字为 Success 数。

表格较宽，可左右滑动

模型	框架	总计	U	B	K
Claude Mythos Preview	Claude Code	157	107	38	12
Claude Opus 4.6	Claude Code	15	12	2	1
Claude Opus 4.7	Claude Code	7	4	3	0
Gemini 3.1 Pro	Gemini CLI	12	10	2	0
GLM-5.1	Claude Code	4	4	0	0
GPT-5.4	Codex CLI	54	38	15	1
GPT-5.5	Codex CLI	120	71	27	22

• 作者解读：作者认为，完整利用仍具挑战性，但部分前沿配置已能完成真实漏洞利用；内核任务成功是其关注的能力信号。
• 例外与拒答：Claude Opus 4.7 成功数低于4.6。作者观察到4.7和 Gemini 常因判断漏洞不可利用而提前结束；GPT-5.4、GLM-5.1 分别出现36、23次安全拒答。
• 安全过滤器：GPT-5.5 恢复默认过滤器并使用默认提示词时，88.2%的任务在任何工具调用前被阻止；其余任务平均4.4次有效 LLM 请求，作者报告均停留在侦察阶段。

开启系统防护重跑

Table 5 仅重跑此前成功任务。下表为关闭防护成功数→开启防护后成功数，不能当作全基准开启防护后的独立评测。

表格较宽，可左右滑动

模型	Userspace	V8	Kernel
Claude Mythos Preview	107→25	38→17	12→3
Claude Opus 4.6	12→0	2→0	1→0
Claude Opus 4.7	4→0	3→0	0→0
Gemini 3.1 Pro	10→0	2→0	0→0
GLM-5.1	4→0	0→0	0→0
GPT-5.4	38→2	15→0	1→1
GPT-5.5	71→10	27→3	22→8

• 作者解读：作者认为，常见缓解措施阻止了多数利用，但部分智能体仍能适应防护。该表没有分解单个防护开关的独立影响。
• 失败案例：Figure 4 的 GPT-5.4 V8 案例在关闭防护时完成代码执行；作者报告，恢复相关防护后不再成功。

取得 flag 与利用指定漏洞

• 指标差异：Table 4 中 Mythos Preview 为226次 Flag、157次 Success，对齐率69.5%；GPT-5.5 为210、120、56.7%。作者称，部分轨迹转向邻近漏洞或其他攻击面。
• 专家验证：59条轨迹由两位作者独立标注并裁决分歧，排除1条双方均不确定的轨迹，剩58条。GPT-5.5 裁判匹配58/58、κ=1.00；Claude 匹配56/58、κ=0.931。
• 生产审查：排除 Anthropic 实验，313项受审任务中两裁判一致294项（93.9%）。Claude 在专家验证中的两次错误均把其他漏洞利用判为指定漏洞利用。

时间预算与成功集合

• 延长运行：Figure 2 使用6小时上限，仅比较 Mythos Preview 与 Opus 4.6。文字图可读到终点标注204和16，以及2小时附近的127和15；其中127与 Table 3 的157不同，论文未解释差异。
• 曲线解读：作者称 Opus 4.6 在前30分钟后趋于平台，而 Mythos Preview 在2小时后继续增加成功。所给文本看不到曲线形状，不能独立核验走势。
• 互补结果：Figure 3 标出 Mythos Preview 独有56项、GPT-5.5 独有26项、其他模型独有4项；正文报告前两者共享91项，纳入延长运行后的总并集为239项。

其他消融与分析

• 费用与调用：Table 3 中 GPT-5.5 全基准平均费用34.55美元、375.4次 LLM 调用；成功子集为22.99美元、256.8次。
• 案例轨迹：Figure 4 标注 GPT-5.4 V8 案例耗时71分钟、费用15.80美元；这里只报告结果，不复述利用构造。

作者明确区分了任务失败、漏洞不可利用和评测预算带来的影响。

作者指出的局限与后续方向

• 目标范围：不覆盖 Windows、iOS、Android 及其应用（第5节 Limitations）。
• 成功指标：代码执行指标不记录任意读写原语、不伴随代码执行的沙箱逃逸或部分利用进展（第5节）。
• 失败解释与真值：失败可能源自安全拒答、工具误用或漏洞不可利用；并非每项任务都有已知完整利用。作者同时认为，完整解答未广泛公开有助于缓解数据污染问题（第5节）。
• 尝试与资源：每任务仅一次、受时间和费用约束的尝试；增加尝试或资源可能提高成功率（第5节）。
• 指令设置：一套指令可能偏向某个模型，定制指令或增加任务上下文可能提高成功率（第5节）。
• 专用工具：没有提供漏洞分析或利用专用工具，作者认为集成这些工具可能提高成功率（第5节）。

实验覆盖范围

• 软件与规模：898项任务分为520项 Userspace、185项 V8 和193项 Linux kernel（Table 2）。
• 配置比较：Table 3 的模型与框架配对固定；Mythos Preview 使用额外指令，评审流程也有 Anthropic 实验例外（第4节）。
• 防护评测：Table 5 对关闭防护时已成功的任务开启标准防护重跑；未报告各开关的独立消融结果。
• 预算分析：主实验每任务2小时；6小时分析仅涉及 Mythos Preview 与 Opus 4.6（Figure 2）。
• 人工一致性：裁判验证基于58条有确定专家标签的轨迹；生产阶段另报告313项非 Anthropic 实验的双裁判一致性（第4节）。

ExploitGym 是面向智能体真实漏洞利用能力的评测基准，重点区分“触发一个 bug”与“取得未授权代码执行”。

• 任务设计：基准提供源码、PoV、漏洞说明和运行环境，默认隐藏补丁。取得动态 flag 后，还须审查是否使用指定漏洞，避免把其他漏洞造成的成功记入主指标。
• 主实验：在898项任务、关闭系统防护、每项2小时的条件下，Claude Mythos Preview／Claude Code 成功157项，GPT-5.5／Codex CLI 成功120项（Table 3）。
• 内核结果：同一设置下，GPT-5.5 完成22项 kernel 任务；作者将此类成功视为应对复杂利用环境的能力信号（Table 3）。
• 防护与指标：对先前成功任务开启防护重跑，Mythos Preview 的 V8 成功数从38变为17（Table 5）。GPT-5.5 的 Flag 为210次、指定漏洞 Success 为120次，二者不能混用（Table 4）。
• 证据边界：作者没有为每项任务提供完整利用真值，主评测也只有一次预算内尝试；因此失败不能直接解释为缺少利用能力，成功数也不是所有漏洞可利用性的真值。
• 作者结论：作者认为，智能体自主开发利用已成为需要纳入威胁建模的能力；当前成功率不能作为长期安全保证，传统加固措施仍需结合面向自主利用的评估。