AI说它挖到了漏洞，凭什么信？

原创

大白
大白

知白守黑1024

2026年11月12日 06:36
北京

去阅读

先说一个很多人都遇到过的场景。让 AI 帮你测一个站，它跑得挺欢，最后交来一份报告：SQL 注入、SSRF、越权，一条条写得头头是道。你挑了一条想复现，打不出来。再挑一条，还是打不出来。

这不是 AI 不行，是它分不清“看起来像漏洞”和“真的是漏洞”。GitHub 上有个叫 Pentest-AI 的开源项目（命令行工具叫ptai，1821 Star，MIT 协议），就是冲这个问题来的：它给每个发现设了两道门槛，机器预言机验证过的才叫 verified，验证不了的永远叫 candidate。模型自己说了不算。

01先说一个尴尬的现实

用大模型跑渗透，最贵的不是 token，是人肉复现的时间。模型的推理是概率性的，它会把“像”当成“是”，幻觉结论混在真实漏洞里，一笔一笔全靠安全工程师自己验。放到赏金场景更现实：交一份复现不了的报告，赔的是你在平台上的信誉分。

Pentest-AI 的思路是把结论权从模型手里拿走。你自己的 AI 客户端（Claude Code、Codex、Cursor 都行）负责驱动调查、提假设、调工具，但“这个发现算不算实锤”，由独立的预言机说了算。README 里那句原话挺妙：

模型的猜测，永远不能穿着结果的外衣交货。（the model's guesses never arrive dressed as results）

02它的办法很朴素：重打一遍，再打个对照

预言机做的事不难理解，难的是多数工具根本不做。发现可疑行为之后，预言机会把漏洞利用重放一遍，同时跑一个对照组，也就是一个本不该触发弱点的请求。两边行为有差异，才算数。

拿可信头绕过举例：带攻击头时必须返回特权内容，不带时必须被拒绝。如果一个服务器对什么都回 200，这不叫证据。

candidate 到 verified 的判定流程（图源项目 README）

真实画面长这样。Juice Shop 靶场上，JWT alg:none 伪造被预言机重放验证，接受了 8 次，绿色那个 VERIFIED 就是机器盖的章：

预言机实战画面，截取自项目官方演示

证据链也是齐的。一条 verified 记录会带上预言机是谁、发了哪些请求、判读了哪些响应。想复核随时可以：ptai retest重跑检查，ptai diff看变化，ptai replay重放证明胶囊。有个细节我挺喜欢，作者特意写明胶囊没有签名。信任机制不是签名，是你随时可以重跑复验。

03家底有多少，CI 每天替它数着

官方维护着一张能力清单，数字全部由 CI 从代码里自动统计核对，文档想吹牛都难：

18 个领域代理覆盖的面相当广：侦察、Web、API 安全、云、移动、无线、域渗透、提权、漏洞链编排，甚至有 LLM 红队和社工模拟。

不过作者把丑话说在前面：不是每个探针都有配套的验证配方，没有配方的发现只能停在 candidate。所以这张表是库存清单，不是战绩。

04成绩单，连作假的空间都留得很小

基准成绩全部公开原始工件。任何人把蜜罐 clone 下来重跑一遍，就能对出这些数字：

官方成绩图（ptai 1.4.0）：90 个范围内的 HTTP 端点命中 81，12 项预言机实锤，0 误报

当然口径也要说清楚：一次扫描没有 verified，不代表这个应用安全。认证后的页面、有状态的流程、不支持的漏洞类型，都在覆盖之外。

05我最喜欢的是赏金模式：把规矩写进代码

1.6.0 加的赏金模式，是我在同类工具里没见过的克制。每个项目一份 TOML 画像，范围、排除、官方声明速率、你的研究者署名，全是硬约束：

~/.pentest-ai/programs/acme.toml

platform =\"hackerone\"

researcher =\"your-h1-username\"# 每个请求都带 X-Bug-Bounty

rps =5.0# 项目方声明的速率

scope = [\"\*.acme.com\",\"api.acme.com\"]

excluded = [\"status.acme.com\"]# 排除优先于通配

细到什么程度？每个请求都被压在声明速率内，外部工具发的也一样，压不住的工具直接跳过并如实说明。范围外请求一律拒绝。gobuster、ffuf 这种字典轰炸工具不给跑，内置发现探针只打五百来个高概率路径。目标回 429，扫描就跟着降速；持续降级就停下，把原因记下来。项目方声明禁止扫描器的，要你手敲一个 yes 才继续，因为那可能作废安全港协议。

还有一组实测数字挺实用：3 rps 全量大概 8700 个请求、51 分钟，找出的 critical 和 high 跟 10 rps 一样多，那边是 6600 个请求、11 分钟。慢，但不漏。对要按速率合规的赏金猎人来说，这就是能抄的作业。报告草稿只从 verified findings 里出，复现步骤直接取预言机的请求记录。

06想试试的话，有三条路

最省事的先跑 demo。不用 API Key，也不打外部目标，测一个自带漏洞的应用，顺便看看证据胶囊长什么样：

$pipx install ptai

$ptai demo

无需 API Key，测自带靶场并演示证据胶囊

接入实拍：注册之后一句自然语言就能驱动完整渗透会话（截取自项目官方演示）

要在自己的 AI 客户端里用，ptai setup --mcp会自动注册到检测到的客户端，已有配置不会动，不放心可以先加--dry-run看一眼。模型由客户端出，MCP 服务器不需要单独的 Key。

想完全本地化就配 Ollama，拉一个支持工具调用的模型，数据不出本机，findings 存在本地 SQLite。进 CI 就一句--ci --fail-on verified，再用 engagement ID 导出 SARIF 交给工程侧。

07最后说点扫兴的

三条，都是作者自己写在文档里的。

一，verified 只对测试条件负责。一次扫描没发现东西，不代表这个应用安全。

二，盲洞验证可能出网。盲测会用到带外协作服务器，回调元数据对方看得见。敏感环境换自建--oast-server，或者--no-oast直接关掉。

三，报告要自己复现了再交。作者原话是：你要亲手复现每一个，自己提交。工具把证据链铺好，最后一公里的判断还是你的。

点击下方卡片，回复关键词20261112获取项目地址。觉得有用的话，点个赞或者转给同事，下篇见。

仅供安全学习与研究。测试仅限自有或已获明确授权的系统，遵守目标项目方规则与当地法律法规；未经授权的测试属违法行为。