Claude 漏洞修复看似强劲，直到维护者测试来评判修复质量

一项新研究显示，Claude 生成的漏洞补丁通过了 90.2% 的崩溃测试，但只有 60.7% 的补丁通过了维护者编写的测试。这 29.5 个百分点的差距改变了表面成功所代表的含义。阻止某一个恶意输入使程序崩溃，并不能证明底层漏洞已被正确修复。

西北大学研究人员 Dang K Le、Wenxuan Shi 和 Xinyu Xing 于 10 月 7 日公布了这项结果。他们的基准可靠性研究考察了来自 84 个开源项目的 112 个历史漏洞。数据集涵盖 C、C++、Go 和 Rust 软件。

该论文质疑了用于评估 AI 编程代理的评分体系。许多基准测试只要概念验证（PoC）不再触发报告中的故障，便会为补丁判定成功。但维护者通常期待更多。修复必须保留预期行为、解决根本原因，并能经受原始报告未覆盖的相邻输入考验。

这种冲突让模型开发者、基准设计者和企业安全团队都面临压力。Claude 和其他编程代理越来越擅长满足可见测试，但现有证据并未显示，它们在生成能够获上游维护者接受的补丁方面取得了同等进展。

Claude 漏洞修复评分掩盖了两种截然不同的结果

研究发现，通过崩溃测试与产出可接受的安全修复，并不是等价的成就。

研究人员通过 OpenCode 代理运行相同的 112 个案例，仅更换底层 Claude 模型。他们测试了 Claude Sonnet 4.0、Sonnet 4.5 和 Opus 4.7。每次运行都会获得构建和测试说明，但不会获得 PoC 的具体内容。

Sonnet 4.0 在 77.7% 的案例中阻止了所提供的 PoC。Sonnet 4.5 达到 84.8%，Opus 4.7 则达到 90.2%。单看这一进展，似乎表明自动化漏洞修复正接近饱和。

但面向维护者的结果讲述了不同的故事。Sonnet 4.0 仅在 43.8% 的案例中通过开发者测试；Sonnet 4.5 达到 48.2%，Opus 4.7 达到 60.7%。

因此，Opus 在两项指标上均有提升，但二者之间仍存在明显差距。在通过 PoC 的 Opus 补丁中，仍有 32.7% 未能通过开发者测试。这大致相当于每三个表面成功案例中就有一个失败。

研究人员还衡量了常规回归测试，即检查此前已测试的行为是否仍能正常运行。Opus 4.7 在 94.6% 的案例中通过了这些测试。这个高分并未消除开发者测试分数显著偏低的问题。

这种区别至关重要，因为旧有回归测试套件很少会编码新的安全修复背后的具体设计决策。它们可以确认熟悉的行为仍然完整，却可能遗漏仅在已报告故障附近做出的浅层修补。

研究中的开发者测试来自上游修复提交。这些单元测试或集成测试由项目自身开发者在修复各个漏洞时编写。AI 代理生成补丁后，研究人员重建了这些新增测试并将其应用于补丁。

这种方法考察生成的代码在漏洞附近是否按维护者预期运行。它不要求 AI 复现维护者补丁的文本。只要行为符合项目接受的语义，替代修复方案仍可通过测试。

该数据集还设置了四道连续关卡。打补丁后的项目必须能够构建、在重复运行中阻止 PoC、通过现有回归测试套件，并通过新增的开发者测试。只有清除每一关，案例才被计为完全解决。

公开的评分分析聚焦于三分之一的失败率，因为它反映了实际风险。即使许多被接受的补丁未通过最贴近维护者意图的测试，一个吸引眼球的标题分数依然可能成立。

这并不能证明 Opus 4.7 不擅长安全工作。它表明，所报告的能力高度取决于基准如何定义成功。无需改变模型或其补丁，评分规则就能改变结论。

阻止崩溃不等于修复漏洞

PoC 只能证明某一种故障消失了，不能证明易受攻击的行为已在其有效运行范围内得到修复。

概念验证通常会提供一个可复现漏洞的输入。对于内存安全漏洞，它可能触发 sanitizer 崩溃；对于逻辑缺陷，它可能展示无效状态或被禁止的操作。

这种输入很有价值，因为它让故障变得具体且可重复。然而，它只暴露程序中的一条路径。代理可以封堵这条路径，却未必理解支配受影响函数的更广泛契约。

西北大学的论文以一个涉及 range() 函数的历史 PHP 漏洞说明了这一问题。混合输入类型可能被错误分类，导致 PHP 将非字符串值当作字符串访问。其中一个提供的输入会导致崩溃。

一种防御性补丁可以通过立即拒绝混合类型来阻止崩溃。它会满足 PoC，并保留许多此前测试过的行为。但它也会拒绝 PHP 本应强制转换的有效混合数值和字符串输入。

上游修复则改变了错误的分类逻辑，同时保留了这一预期行为。开发者为一个相邻的有效输入添加了测试，从而将真正的修复与限制性变通方案区分开来。

这正是评分问题的核心。只检查崩溃输入的基准，会给这两种补丁相同的分数。维护者测试则会拒绝那个将受支持行为变成错误的补丁。

安全代理有很强的动机去优化评估者能够观察到的内容。当崩溃是主要判定依据时，在崩溃点附近增加一道防护检查可能是合理回应。判定器只是用于决定输出是否正确的机制。

这种补丁或许适合作为紧急缓解措施，但不应自动被标记为完整修复。这一区别会影响代码审查、部署决策，以及分配给自主系统的信心程度。

这个问题在自动化程序修复领域早已存在。补丁可能像统计模型对训练数据过拟合一样，对测试套件过拟合。它满足了现有示例，却未能捕捉底层需求。

安全问题提高了这种错误的代价。表面化补丁可能制造虚假的安全感、压制可见症状，或将缺陷转移到未测试路径。审查者随后可能会减少对带有自动化成功标签代码的审查时间。

一项相关的补丁验证研究推出了覆盖 20 个项目、209 个案例的 PVBench。研究人员发现，超过 40% 通过基础测试的补丁，未能通过依据开发者修复方案新增的测试。

尽管两个数据集和评估设计不同，这一独立结果仍支持了更广泛的担忧。反复出现的教训是，基础功能检查和单一漏洞利用输入仍有重要行为未被衡量。

因此，Claude 的漏洞修复能力应被视为分层能力。模型必须定位原因、修改正确的逻辑、保留合法行为，并避免引入新弱点。阻止一次崩溃只能验证这条链条的一部分。

基准设计无需改善补丁，也能改变评分

提示细节、工具访问权限和测试呈现方式都能提高测得的性能，即使与开发者标准一致的质量几乎没有变化。

西北大学研究人员测试了构建说明如何影响同一模型和数据集。在提供详细构建和测试命令时，Sonnet 4.0 通过了 77.7% 的 PoC；没有这些说明时，通过率为 74.1%。

总体差异看起来不大，但在语言层面的结果要大得多。对于 C 和 C++ 案例，提供说明使 PoC 通过率从 72% 提升至 92%。

该组的开发者测试通过率仅从 28% 升至 36%。在所有语言中，这一比例从 41.1% 增至 43.8%。更好的说明主要帮助代理操作测试框架并确认可见结果。

这一结果并不意味着提供说明不正当。人类工程师同样受益于文档化的构建命令。它意味着，除非披露各自的信息预算，否则不同基准的分数无法安全比较。

编程语言惯例又增加了一个变量。Go 和 Rust 项目往往提供可预测的构建和测试命令。C 和 C++ 仓库则使用更加多样的构建系统、标志、封装脚本和项目特定流程。

无法发现这些命令的代理，可能在补丁获得有意义评估之前就得到失败分数。反过来，经过精心准备的提示可以消除配置工作，使同一模型看起来具备明显更强的能力。

PoC 的呈现形式带来了另一项显著差异。在 62 个 Go 案例中，向代理展示源代码级 PoC，使其崩溃测试分数从 69.4% 提高到 95.2%。开发者测试表现则从 41.9% 升至 48.4%。

源代码测试框架揭示了被调用的 API 以及问题调用的形态。这些上下文帮助代理与可见测试对齐，但在面向维护者的指标上只带来了小得多的提升。

对于 25 个 C 和 C++ 案例，暴露不透明的二进制或文本输入并未改变 PoC 分数，仍为 92%。开发者测试分数也维持在 36%。

两种基准配置都可以如实声称自己向代理提供了 PoC，但它们提供的信息并不等价。一种暴露了可执行意图，另一种只提供了必须推断其含义的输入文件。

工具访问会带来更直接的污染风险。历史漏洞往往已有公开议题、安全公告和上游补丁。具备网络访问能力的编程代理可以搜索议题编号并获取已接受的修复方案。

论文记录了一个案例：代理在写出答案前使用网络工具找到了上游补丁。另一个案例则通过未经清理的 Git 历史暴露了先前修复。两者都生成了成功补丁，但都无法纯粹衡量独立修复能力。

真实开发者经常搜索网络并检查仓库历史，这些做法在生产环境中很合理。只有当基准声称要衡量在历史任务上的无辅助推理时，它们才会成为问题。

因此，评估必须说明其预期衡量的能力。工具使用基准可以允许搜索，并奖励有效检索；模型推理基准则必须将案例与答案泄露隔离开来。

基础设施错误也可能从相反方向扭曲结果。错误的权限设置可能暴露隐藏的真实答案，或阻止合法构建。超时可能惩罚运行缓慢的项目，而测试文件冲突则可能将正确补丁标记为失败。

研究人员观察到，在完整运行中，单项框架问题影响了约 5% 至 32% 的案例。这些比例可能超过排行榜上两个名次之间的分数差距。

实际结论并不是所有基准分数都毫无价值，而是一个分数属于完整系统的一部分，其中包括提示、工具、源代码打包方式、执行限制和评分流程。

真正的较量是基准成功与维护者接受之间

核心冲突已不再是 AI 智能体能否写出看似合理的补丁，而是其成功信号是否与生产环境的验收标准一致。

AI 漏洞修复供应商受益于简洁的性能数字。买家在选择模型或评估安全智能体时，也希望有简单的对比方式。这些动机促成了以单一可见成功率为核心的排行榜。

维护者的定义则没有那么方便。他们必须判断一项改动是否修复了根本原因、保护了受支持的行为、遵循了项目惯例，并且在数月后依然易于理解。

西北大学的数据集试图将其中一部分判断纳入自动化评估。由维护者编写的测试并不能完全替代审查，但相比单一崩溃输入，它们编码了更多意图。

其他研究人员也在朝类似方向推进。PatchBench results 发现，在 11 个智能体中，仅采用 PoC 验证会使解决率平均夸大 1.83 倍。该基准加入了安全重放、单元测试和输出检查。

PatchBench 还处理了记忆化问题。它选择了已接受修复位于报告崩溃栈之外的漏洞，随后将漏洞移植到发生变化的代码仓库上下文中，以降低回忆历史补丁的价值。

其表现最强的智能体通过了超过 97% 的原始 PoC，却只在结合安全与语义验证的条件下解决了约一半任务。这一模式与西北大学指出的评分差距高度相似。

伯克利研究人员通过一项端到端基准测试得出了更乐观、但并不矛盾的结论。CyberGym-E2E 覆盖 139 个开源项目中的 920 个漏洞，并同时测试发现、复现和修复能力。

在获得目标漏洞信息时，其最佳配置修复了约 80% 的案例。当智能体必须先发现问题时，端到端表现有所下降。研究人员还观察到一些浅层补丁：它们防住了报告中的崩溃，却保留了更深层的缺陷。

这些研究并未给出一个通用排名。它们使用了不同的任务、智能体、模型代际和定义。但合在一起，它们说明了为何单一百分比无法代表完整的防御工作流。

更严格的标准不应要求文本上匹配历史补丁。软件缺陷往往存在多种有效修复方式。基于补丁相似度的基准可能仅因一个更清晰的替代方案修改了不同函数，便将其拒绝。

行为评分是更好的方向。它应测试报告中的利用方式、相邻输入、受支持功能、安全属性和项目特定期望。对于无法编码的要求，人类审查仍不可或缺。

企业团队在采购时也应采用同样的区分。若不了解评分背后的判定标准、环境、工具权限和失败类别，供应商的修复分数便并不完整。

有用的问题应当具体：智能体是否获得了利用代码？它能否访问互联网或 Git 历史？成功是否要求通过维护者测试？流水线错误是否与错误补丁区分开来？

团队还应询问结果是否涵盖补丁回归、替代利用路径和新引入的弱点。一个阻止了某种利用却暴露另一种利用方式的补丁，并不能算作站得住脚的成功。

这一标准提高了对 Claude 漏洞修复以及所有竞争系统的要求。它也为模型开发者提供了比单纯提高 PoC 通过率更清晰的目标。

该研究证明了什么，又没有证明什么

证据表明基准测试具有敏感性，但并未确立 Claude 或所有生产安全工作流的通用失败率。

该论文是一篇发布于 2026 年 10 月的 arXiv 预印本。其主张应被视为研究发现，而非对自主修复可靠性的最终、全行业衡量。

其 112 个案例覆盖四类语言和 84 个项目，为分析提供了有价值的多样性。然而，入选条件要求构建可复现，且上游提交包含有意义的测试。这一选择并不代表生产环境中发现的每一种漏洞。

开发者测试比仅检查 PoC 更强，但仍只是维护者验收标准的不完整代理。项目新增的测试捕捉的是部分预期行为，而非所有性能、兼容性、可读性或架构方面的考量。

生成的补丁也可能未通过历史开发者测试，却依然具有合理性。替代修复可能有意改变某项未文档化行为，或封闭更广泛的攻击面。人类维护者可能会在审查后接受这种权衡。

该研究通过采用上游修复中编写的测试来减轻这一问题，但并未消除逐一检查分歧的必要性。测试失败意味着不一致，并不自动代表补丁具有危险性。

历史数据带来了另一项限制。公开问题、公告和修复可能已出现在模型训练数据中。研究人员承认，记忆化可能影响绝对成功率。

不过，它们的受控对比仍然有价值，因为在改变基准条件时保持了模型和漏洞不变。仅靠记忆化无法解释为何提示细节或判定标准的选择会改变测量结果。

实验还采用了特定的智能体与模型组合。受控测试将 OpenCode 与 Claude 模型配对，案例研究则将 Claude Code 与 Sonnet 4.5 配对。不同的脚手架可能产生不同的搜索、编辑和验证行为。

生产环境中的 Claude 漏洞修复可能包含组织特定测试、静态分析、模糊测试、代码审查和分阶段发布。这些控制措施能够捕获学术测试框架记录为不成功输出的失败。

反过来也同样成立。生产代码仓库可能包含不完整的测试、未文档化的行为，以及无法在干净容器中获取的依赖项。真实部署可能比经过筛选的基准更困难。

负责任的结论比营销说辞或一概否定都更狭窄。Claude Opus 4.7 在该数据集中相较早期 Claude 代际有实质性提升。但其崩溃测试分数仍比开发者对齐结果高出 29.5 个百分点。

安全团队应将生成的补丁视为需要证据支持的候选方案。该研究不支持仅凭 PoC 停止触发和旧版测试套件全部通过，就进行无人值守部署。

三个信号将显示 AI 修复是否正在变得可信

进展如今取决于更严格的评分、透明的评估流水线，以及生成修复能够经受独立审查的生产证据。

第一个信号是更广泛采用开发者意图或语义测试。未来模型发布应同时报告 PoC 成功率，以及围绕已接受程序行为设计的测试表现。

差距缩小将增强模型正在学习修复根本原因这一论点。若崩溃测试分数上升而维护者测试差距保持稳定，则会削弱这一论点。

第二个信号是完整披露基准测试。评估者应公开提示词、工具权限、网络访问、源码清理方式、超时设置、测试应用错误以及各阶段结果。

这很重要，因为当智能体获得构建说明、可读的 PoC、网页访问权限或隐藏的仓库历史时，分数都可能发生变化。可复现的产物让研究人员能够将模型进步与测试框架提供的辅助区分开来。

独立工作正开始覆盖更广泛的防御闭环。Cyber Index methodology 将代码仓库审计、漏洞发现、复现和修复结合起来，同时不破坏合法行为。

第三个信号是来自经过审查的生产补丁的证据。组织应追踪生成修复被原样接受、由维护者修改、被拒绝或随后发生安全回归的频率。

这一验收漏斗比在受控测试套件中被抑制的崩溃数量更重要。它衡量自动化输出是否在不将隐性风险转移至下游的前提下减少工程工作。

对于即时使用，团队可以采用分层关卡：要求利用停止生效，运行旧有回归测试，加入边界案例，在可行处应用模糊测试，并在部署前取得人工审查。

他们应保留智能体的提示词、工具轨迹、补丁和验证结果。一个可搜索的工程知识库可以帮助团队比较不同代码仓库中反复出现的失败模式。

买家面临的问题不再是 AI 智能体能否让一项失败测试变为通过，而是这一通过结果是否代表生产软件所要求的安全属性、受支持行为和维护者意图。

在信任下一项 Claude 漏洞修复分数之前，先问评分器能看到什么。再问它从未测试过什么。