AI 明明猜对了漏洞，为什么还是挖不出来？ProjectDiscovery 的一项研究挺有意思
最近看了 ProjectDiscovery 在 2026 年 9 月 7 日发布的一篇研究：Chain-of-thought analysis of agents on offensive security tasks。
这篇文章研究的问题其实挺有意思：
如果平时用过 LLM 做渗透测试，应该对这个情况不陌生。
比如把一个 API 的请求和响应丢给模型，它能分析出 IDOR、SSRF、SQL 注入、权限绕过等一堆可能性，有时候思路确实不错。
但如果把工具也交给它，让它自己去完成整个过程，情况就不一样了。
可能一开始方向选得很准，后面却一直构造不出有效的请求；也可能明明已经拿到有价值的响应，结果没看出来；还有时候会反复测试同一个东西，最后 Token 花了一大堆，漏洞一个没验证出来。
ProjectDiscovery 这次研究的就是这个问题。
一、54 个安全挑战，87% 的成功案例第一次就猜对了
研究人员挑选了 54 个安全挑战，让不同模型在没有目标源码的情况下，自主使用工具寻找并利用漏洞。
其中一个结果挺出乎意料：
注意，这不是说 AI 挖洞的成功率有 87%，而是说那些最终成功的案例，大多数从一开始就找准了方向。
比如遇到一个 PDF 渲染服务，模型很快就能想到 SSRF；看到某些涉及资源 ID 的接口，会考虑越权；遇到文件处理功能，会优先检查上传、解析或者路径相关的问题。
这和我们平时人工挖洞其实挺像的。
一个有经验的安全研究员，看到目标的功能，通常也不会把所有漏洞类型挨个测试一遍。
比如看到一个订单接口，我更关心用户能不能操作别人的订单、金额是不是由服务端重新计算、订单状态能不能跳过正常流程。
而不是上来就把 SQL 注入、XSS、目录遍历全部跑一遍。
大模型在这方面已经有一定能力了。它学过大量漏洞案例，知道什么功能通常容易出现什么问题，也能根据接口语义提出比较合理的猜测。
但问题是，猜到可能存在什么漏洞，和真正把漏洞验证出来，完全是两回事。
二、给 Agent 塞一堆安全测试流程，效果可能还不如不塞
研究人员还做了一个对照实验。
两个 Agent 使用相同的基础工具，区别是一个被提供了完整的安全测试方法清单，另一个没有额外的方法清单。
有方法清单的 Agent，需要考虑信息收集、枚举、各种常见安全工具和测试步骤。
没有方法清单的 Agent，则可以根据当前目标自行决定怎么测试。
结果是什么？
| 对比 | 完整方法清单 | 无额外方法清单 |
|---|---|---|
| 工具环境 | 相同 | 相同 |
| 发现数量 | 接近 | 接近 |
| 运行成本 | 约 350 美元 | 约 35 美元 |
为什么？
研究人员看了执行轨迹以后发现，有方法清单的 Agent 特别容易把那些指导内容当成必须执行的任务。
哪怕已经发现一个很值得验证的方向，它还是倾向于先去完成侦察、枚举等既定步骤。
这让我想到现在不少 AI 渗透测试项目的设计思路。
很多项目喜欢给 Agent 配一整套工作流：先跑子域名，再扫端口，然后识别指纹、爬接口、跑漏洞模板，最后把结果交给 LLM 分析。
这些步骤本身当然有价值，问题是，不是每个目标都需要完整走一遍。
如果当前已经有足够证据支持某个漏洞假设，为什么不能直接设计实验去验证？
反过来，如果连目标的认证方式、业务逻辑和资源关系都没搞清楚，那继续跑再多 Payload，可能也没什么意义。
不过，这个实验也不能理解成以后就不需要信息收集了。它只能说明，在研究使用的这些挑战中，强制执行完整方法清单没有带来对应的收益。
三、最值得关注的结果：不到 1% 的失败是因为知识不够
这应该是整篇研究里最值得关注的发现。
研究人员把 Agent 的失败分成了三种情况。
简单说，就是模型根本不知道这里可能存在什么漏洞。
比如一个接口存在某种访问控制缺陷，但是模型完全没有想到这个方向。
这种问题理论上可以通过更好的模型、训练数据或者安全知识来改善。
模型知道应该测试什么，但就是完成不了。
比如已经判断某个接口可能有 IDOR，却没办法正确建立两个用户的会话，也不知道应该如何比较不同身份访问同一个对象的结果。
或者怀疑业务逻辑存在绕过，但不会构造对应的业务状态，导致请求一直失败。
这种情况下，模型的安全知识可能没什么问题，真正的问题在执行。
模型其实有能力完成任务，但是这次没有走对。
同一个模型，面对同一个或者类似的挑战，换一次执行轨迹，结果可能就不同。
有时候它能想到关键步骤，有时候就会被一些无关信息带偏。
这三种情况里，研究人员发现：
剩下的失败主要落在执行能力不足和能力未能有效发挥这两类中。
需要注意，研究人员并没有准确拆分后面两类的比例，所以不能直接说 99% 都是执行能力问题。
但至少说明了一件事：
这其实值得做 AI 安全 Agent 的开发者认真想想。
我们经常把精力放在换更强的模型、扩充漏洞知识库、优化安全提示词上。
但如果模型本来就知道应该测试什么，继续往里面塞更多漏洞知识，未必能解决它当前的问题。
真正需要改善的可能是：
- 能不能把漏洞假设变成实际可执行的测试？
- 能不能理解接口之间的依赖关系？
- 能不能正确处理登录、Token、Cookie 和不同身份？
- 能不能知道一个实验为什么失败？
- 能不能从请求和响应里判断漏洞到底有没有成立？
这些问题不是简单换一个更大的模型就一定能解决的。
四、还有一个有意思的现象：Agent 居然开始研究测试环境了
研究里还有一部分内容挺有意思。
有些 Agent 在目标访问失败，或者正常测试迟迟没有进展时，没有继续研究目标应用，反而开始检查运行环境。
比如搜索本地文件、检查环境变量、查看网络服务，甚至尝试访问测试编排系统。
有些 Agent 还通过读取挑战源码或者环境里的 flag，绕过正常漏洞利用路径完成了任务。
研究人员识别出这些情况后，对相关挑战重新进行了测试。
从某个角度看，这说明 Agent 确实具备一定的自主探索能力。
它发现当前方法不奏效，就尝试寻找别的路径。
但从安全测试角度看，这其实是一个很大的问题。
如果只是本地靶场，最多影响测试结果。
但如果把这样的 Agent 直接部署到真实漏洞赏金环境里，问题就严重了。
例如目标域名访问失败，Agent 可能转而探测代理节点、内部服务或者其他并不在授权范围内的地址。
所以我认为，做自动化漏洞研究，目标授权和执行边界不能完全交给 LLM 自己判断。
模型可以负责决定下一步想研究什么，但真正发送请求之前，还是应该由代码检查目标是否在授权范围内、是否超过速率限制、是否允许执行当前操作。
这一点比提示词里写多少遍“不要越界”更可靠。
五、这项研究对自动化漏洞挖掘有什么启发？
我觉得最重要的不是去模仿 ProjectDiscovery 的测试环境，而是看它暴露出的 Agent 能力问题。
现在不少自动化安全项目，实际上还是传统扫描器加一个 LLM。
扫描器负责收集资产、执行 Payload，LLM 负责分析结果、生成报告。
这当然能解决一部分问题，但对于权限绕过、业务逻辑漏洞以及需要多个接口配合验证的问题，效果可能比较有限。
因为这些漏洞不是靠多发几个 Payload 就能发现的。
举个简单的例子。
假设有一个订单 API：
GET /api/orders/1024
Authorization: Bearer <token>
模型怀疑这里可能存在越权。
但光有这个猜测还不够。
至少还要搞清楚：
当前 Token 属于哪个用户？订单 1024 属于谁？能不能创建另一个用户？两个用户的权限是否相同？不同身份访问相同订单会返回什么？返回的数据是否真的违反了授权规则？
如果连这些关系都没有建立，Agent 就算生成一百个不同的订单 ID，也不一定能证明存在漏洞。
而且，返回 200 OK 不等于越权，返回 403 Forbidden 也不一定代表不存在其他绕过路径。
这就是为什么我认为，未来做自主安全研究，不能只考虑“模型能提出多少种漏洞假设”。
更应该关心它能不能理解目标的实际业务，然后自己设计出有效的实验。
我比较认可这样一个过程：
观察目标
↓
理解接口、身份、资源和业务状态
↓
提出漏洞假设
↓
检查验证条件是否满足
↓
设计并执行实验
↓
分析原始请求和响应
↓
确认、排除或保留假设
↓
继续研究或者停止
这里有两个地方特别重要。
一个是不要把实验失败直接当成漏洞不存在。
请求超时、认证失效、业务状态不满足、参数构造错误，这些都是可能的原因。
另一个是不要把模型认为存在漏洞，当成已经验证成功。
最终还是要看原始证据，能不能证明违反了什么安全约束，以及产生了什么实际影响。
尤其是做真实漏洞赏金，模型写得再像模像样，没有可靠的复现证据，也很难成为一份有效报告。
六、也别把这 54 个挑战的结果看得太绝对
虽然研究结论很有价值，但也有几个地方需要注意。
首先，这 54 个任务来自经过修改和筛选的安全挑战，不是 54 个真实企业的漏洞赏金项目。
其次，挑战通常有比较明确的目标和成功条件。真实 Web 应用要复杂得多，可能涉及多个角色、几十个 API、复杂业务状态，以及各种非预期行为。
另外，研究没有完整公开所有原始数据和复现条件，所以外部研究人员还很难独立核对每一个结论。
还有一个容易忽略的地方：
成功完成挑战，不代表发现的漏洞在真实赏金平台上一定有效，更不代表一定能拿到赏金。
因此，87% 的首次猜测命中率，以及不到 1% 的知识缺口比例，都应该放在这次实验的条件下理解。
不能直接拿它们预测真实环境的漏洞发现成功率。
最后说两句
看完这篇研究，我最大的感受是：
现在的大模型已经能理解不少安全问题，也能提出一些很有价值的漏洞研究方向。
但提出假设只是第一步。
真正困难的是后面那部分：理解业务、准备测试条件、执行实验、处理失败、分析证据，以及判断什么时候应该继续、什么时候应该停止。
我不觉得这篇研究证明了 AI 已经掌握了绝大多数漏洞知识，也不认为它说明传统安全工具和方法论已经没用了。
它真正提醒我们的是：
如果一个 Agent 已经能够提出正确的漏洞假设，那么下一步应该先查清楚它为什么没能完成验证，而不是习惯性地继续往里面增加模型、工具和提示词。
毕竟，我们做自动化安全研究，最终要的是能复现、能证明影响的真实漏洞，不是让 AI 生成一份看起来很专业的扫描报告。
参考资料
- 发布时间：2026 年 9 月 7 日
- 研究团队：ProjectDiscovery
- 研究内容：54 项自主安全任务中的 Agent 执行与推理轨迹分析
- 原文地址：https://projectdiscovery.io/research/chain-of-thought-analysis-of-offensive-tasks