[论文分析]ZeroDayBench：面向网络防御的未知零日漏洞LLM智能体评估

ZeroDayBench: Evaluating LLM Agents on Unseen Zero-Day Vulnerabilities for Cyberdefense论文重点ZeroDayBench是首个专门评估LLM智能体在真实零日漏洞场景下自主发现与修复能力的基准测试集。该研究通过将已知CVE漏洞移植到功能相似但代码不同的开源项目中构建了22个前沿模型训练数据中不存在的高危漏洞任务CVSS ≥ 7.0测试了GPT-5.2、Claude Sonnet 4.5和Grok 4.1三款主流模型的零样本推理能力。研究发现即使在full-info完整信息条件下表现最佳的Claude Sonnet 4.5也仅达到95.7%的通过率而在真正的零日情境下无任何额外信息所有模型的成功率均仅为12%–14%——这揭示了一个核心结论前沿LLM尚不具备自主解决真实零日漏洞修复任务的能力。核心研究内容问题定义随着LLM被越来越多地部署为自主软件工程智能体其在代码库中自主发现和修复安全漏洞的能力备受关注。然而现有的网络安全评估基准存在两个根本性问题一是依赖模糊测试发现的漏洞或历史CVE这些数据很可能已存在于模型训练集中导致评估结果反映的是记忆检索能力而非真正的推理能力二是现有基准多聚焦于低影响漏洞无法反映高风险安全场景的真实需求。ZeroDayBench旨在解决这两个核心缺陷提供一种能够衡量模型零样本推理能力而非记忆能力的评估框架。创新方法1漏洞移植Vulnerability Porting这是ZeroDayBench最核心的技术创新。研究团队并非直接使用已知CVE的原始漏洞代码而是将真实CVE的根因移植到功能相似但代码完全不同的目标仓库中。例如Redis CVE-2023-41056是一个在SDS字符串缓冲区调整大小中导致堆溢出和RCE的整数溢出漏洞团队将其移植到MinIO的wholeBitrotReader.ReadAt()函数中——该函数执行类似的S3对象范围读取缓冲区操作使根因具备了可移植性。这种方法确保了漏洞在训练数据中不存在极大降低了模型通过记忆来作弊的可能性。2五级信息可见度设计研究设计了五个难度级别来模拟漏洞生命周期的不同阶段zero-day仅告知找到并修补一个高危漏洞无任何额外信息cwe给出CWE通用类别如内存破坏漏洞post-exploit提供攻击者成功利用后的影响描述但不指明根因one-day告知具体哪个文件的哪个函数存在漏洞及问题性质full-info提供精确的修复位置和具体操作说明这种设计能够精细测量智能体在不同信息量下的表现揭示模型在真实漏洞响应流程中各阶段的能力边界。3基于渗透测试的评估方法与传统基准仅检查补丁是否生成不同ZeroDayBench引入了自定义的渗透测试评估方法通过验证修复后实时漏洞利用是否被阻止来评判补丁有效性。研究成果定量结果在三款模型的测试中Claude Sonnet 4.5以56.0%的总体通过率位居第一GPT-5.2以48.2%紧随其后Grok 4.1 Fast为34.0%。在zero-day难度下三款模型表现相当12.8%、14.4%、12.1%但随着信息量增加Claude Sonnet 4.5展现出更明显的优势——在full-info条件下达到95.7%的通过率远超GPT-5.2的76.2%和Grok的58.8%。行为分析研究发现了一个清晰的趋势——信息越充分模型成功率越高这符合直觉但同时也说明当前模型在自主漏洞发现真正的零日场景方面能力严重不足。实际落地应用的可能性高可行性方向辅助安全审计在one-day及以上信息级别75%–95%成功率模型已能作为安全工程师的辅助工具在已知漏洞位置和类型的情况下生成有效补丁安全培训与演练ZeroDayBench可作为红队演练的训练平台帮助安全团队测试和提升LLM辅助漏洞修复的能力低可行性方向完全自主的零日漏洞发现与修复在zero-day级别12%–14%的成功率远不能满足生产环境的安全要求取代专业安全研究人员当前模型在缺乏明确指引时表现欠佳无法替代人类专家的判断技术细节漏洞注入技术漏洞注入通过针对性的代码修改实现主要包括将安全库调用替换为不安全的等价调用移除认证检查或输入 sanitization例如移除MLFlow的quote()参数 sanitization 函数以启用 shell 注入CVE-2020-11978将GitPython切换为原始subprocess.run(shellTrue)调用CVE-2021-21300变体设计研究构建了两种类型的任务变体跨仓库变体Cross-repo variation将同一个CVE移植到多个目标中。例如CVE-2021-23017nginx DNS解析器中的off-by-one漏洞被移植到HAProxy、Squid和Tinyproxy三个C语言仓库——它们各自以不同方式实现DNS解析。仓库内变体Intra-repo variation在单个目标中实现同一根因的多种变体。Squid有7个CVE-2021-23017变体通过不同方法引入内存破坏移除长度检查、整数下溢、空字节投毒、双重释放等Mosquitto有3个CVE-2024-42655变体使用不同的ACL绕过方法。智能体架构智能体采用简单的循环架构基础LLM配备两个工具# 伪代码示意classZeroDayAgent:tools[BashTool(# 执行任意bash命令timeout120,# 超过120秒则取消max_output10000# 超过10000字符则截断),EditTool()# 添加和编辑指定文件中的文本]max_turns100# 最大工具调用轮次terminationno tool callsormax turns reached漏洞复盖范围基准涵盖的漏洞类型包括RCE远程代码执行反序列化、命令注入、SSTI权限提升与认证绕过SQL注入内存破坏缓冲区溢出、off-by-one路径遍历涉及的开源项目包括MLFlow、Flyte、Mosquitto、vLLM、Dropbear、HAProxy、Squid、Tinyproxy、Jenkins、Minio、Verdaccio等。研究设定实验配置配置项详情评估时间2026年1月15日至2月1日测试模型GPT-5.2推理设为Medium、Claude Sonnet 4.5、Grok 4.1 Fast启用推理最大工具调用轮次100轮Bash命令超时120秒输出截断阈值10,000字符运行环境Docker容器化环境漏洞来源与筛选漏洞选自NVD和cvedetails.com公共数据库筛选标准包括CVSS评分 ≥ 7.0高危或严重主要攻击向量包括RCE、权限提升、认证绕过、命令注入包含拒绝服务和内存破坏漏洞排除链式漏洞chained vulnerabilities硬件/软件要求核心依赖Docker容器化隔离环境API访问需要GPT-5.2、Claude Sonnet 4.5、Grok 4.1 Fast的API权限计算资源论文未明确说明具体硬件配置但考虑到涉及代码库编译、测试执行和LLM API调用建议具备至少16GB内存和多核CPU的中高端开发机器综合分析研究团队背景与可信度第一作者Nancy Lau是UC Santa Cruz计算机科学与工程系的博士生研究兴趣聚焦于AI智能体的安全性此前有固件安全和CTF竞赛背景。她曾创立本科网络安全俱乐部并在SPAR项目下主导了AI漏洞检测基准的创建。其博士提案聚焦于通过强化学习实现安全编码智能体。共同作者Louis Sloot来自卡内基梅隆大学。HUD AI的Dylan Bowman等作者来自产业界。论文已被ICLR 2026的Agents in the Wild Workshop接收。从团队构成来看该研究兼具学术严谨性UCSC、CMU等顶尖机构和产业相关性HUD AI的参与并非纯理论推演。第一作者在AI安全领域的持续深耕从固件安全到CTF再到AI智能体安全为研究提供了扎实的技术功底。技术真实性评估漏洞移植方法的可行性该方法在技术上是真实且可行的。漏洞的根因root cause往往具有跨代码库的可移植性——例如缓冲区边界检查缺失、输入验证不足等逻辑缺陷可以在不同实现中出现。研究团队选择功能相似的代码位置进行移植如Redis的SDS缓冲区和MinIO的S3范围读取这符合软件安全研究的常规实践。但需要指出的是严格保证这些补丁从未出现在训练数据中是无法做到的——研究团队自己也承认这一点将其定位为降低直接记忆信号的汙染控制方法而非绝对保证。评估方法的有效性基于渗透测试的补丁验证方法比单纯检查补丁是否生成更为严格。这种方法能够有效避免生成看似合理但实际无效的补丁这类假阳性在技术上是扎实的。模型选择的合理性GPT-5.2、Claude Sonnet 4.5和Grok 4.1 Fast是2026年初的前沿模型在先前软件工程基准上表现优异选择这三款具有代表性。核心洞见1零日漏洞修复能力的真实瓶颈12%–14%的zero-day成功率是一个警示性数据。它说明当前最先进的LLM在面对真正未知的漏洞时自主发现能力极为有限。这不是记忆与推理的争论而是根本性的推理能力缺失——模型可以在被告知问题位置后有效修复full-info达95.7%但无法自主定位问题。2信息级别的阶梯效应从zero-day12%到full-info95.7%Claude Sonnet 4.5的性能提升近乎线性。这说明漏洞修复的不同阶段对AI能力的要求截然不同定位漏洞需要深度代码理解和推理远比修复漏洞需要代码生成能力困难。这一发现对安全工具的设计具有重要指导意义——与其追求全自动漏洞修复不如先开发辅助定位自动修复的人机协作模式。3对AI取代安全工程师论调的审慎回应论文结果明确表明至少在零日漏洞防御领域AI远未达到取代人类专家的水平。但这也意味着AI可以作为强大的辅助工具——在人类指明方向后高效完成修复工作。局限性漏洞移植的人工成本高每个漏洞需要人工分析根因、寻找可移植的目标代码位置并进行修改难以大规模扩展评估模型的API依赖测试依赖特定商业模型的API结果可能随模型版本更新而变化仅复盖开源代码库对闭源商业软件的可迁移性有待验证排除链式漏洞现实中的零日漏洞往往是链式的简化了评估场景实践应用对安全工程师的建议1. 将LLM定位为高级修复助手而非自主安全分析师在zero-day和cwe级别12%–33%成功率让LLM自主发现和修复漏洞风险极高。建议的工作流是人类定位漏洞 → LLM生成修复方案 → 人类审查验证。在one-day及以上级别75%–95%成功率LLM可作为高效的补丁生成工具。2. 利用五级信息框架设计人机协作流程ZeroDayBench的信息级别设计本身就映射了真实漏洞响应流程漏洞发现阶段对应zero-day/cwe依赖人类专家的代码审计能力影响评估阶段对应post-exploit人类分析攻击面AI可辅助影响范围评估修复实施阶段对应one-day/full-infoAI高效生成补丁人类审查3. 警惕训练数据汙染问题ZeroDayBench的漏洞移植方法提醒我们使用历史CVE数据训练或评估的AI安全工具可能存在严重的过拟合风险。在采购或部署AI安全产品时应要求供应商提供在未见漏洞上的评估数据。对研究者的建议1. 扩展漏洞移植的自动化程度当前人工移植成本高、规模小仅22个任务。未来研究可探索自动化漏洞模式提取与移植方法以构建更大规模的零日评估基准。2. 研究定位能力与修复能力的解耦论文暗示模型的定位能力远弱于修复能力。这是一个值得深入研究的切入点——是否可以单独训练或微调模型的漏洞定位能力是否可以开发专门的漏洞定位智能体与漏洞修复智能体协作3. 探索强化学习在安全智能体中的应用第一作者Nancy Lau的博士研究恰好聚焦于此——通过RL实现安全编码智能体。ZeroDayBench可作为这类研究的评估平台测试RL增强的智能体是否能在zero-day场景中超越纯LLM方法。参考资料来源原始论文: https://arxiv.org/pdf/2603.02297ICLR 2026 Workshop “Agents in the Wild”: https://iclr.cc/ Workshop信息作者信息: UC Santa Cruz (Nancy Lau), Carnegie Mellon University (Louis Sloot), HUD AI (Dylan Bowman, Mario Brajkovski, Jaideep Chawla), New York University (Dan Zhao)