AI 漏洞挖掘，突破口不只在模型里

最近面试安全工程师，一个很直观的感受是：同样借助 AI，漏洞挖掘的路径已经有了很多变化。

有人从复现 CVE 入手，希望理解根因，再寻找同类缺陷；有人专门解决反射、动态调用和复杂调用链；有人把目光放到多个系统之间，分析一个系统的输出如何成为另一个系统的输入；也有人优先研究触发条件少、容易确认的问题，先把发现和复现做扎实。

这些方向都有价值。但假设大家都能获得接近的模型和工具，还能靠什么持续找到不同的问题？

我更关心的是：除了让 AI 阅读更多代码，能不能让它检查过去没有被充分检查的关系？

代码与运行环境之间，上游保证与下游依赖之间，程序判断与业务要求之间，安全上下文与内部表示之间，以及局部能力与完整操作序列之间，都值得重新审视。

沿着这些关系，可以把“帮我看看有没有漏洞”拆成更具体的研究问题。下面几个公开 CVE 提供了真实的根因，也提供了值得尝试的 AI 挖掘切口。

四类关系，比漏洞类型更值得搜索

很多看似不同的漏洞，最终都可以归到四类关系：变化、边界、状态、组合。这四类不是漏洞分类法，而是给 AI 限定搜索空间的方法：先明确要检查哪一种关系，再选择代码、历史补丁、运行轨迹和实验作为证据。

研究维度	核心问题	典型切口
变化	什么旧前提已经不成立？	依赖升级、历史补丁、Backport、重构、新入口
边界	两个组件证明、表示或解释的是同一件事吗？	Trust Contract、Parser Differential、Validation Chain
状态	安全属性在什么时候建立、复制、降级或丢失？	Pre-auth State、Context Reuse、Ownership/Lifetime
组合	为什么局部正常，组合后仍能形成危险能力？	Capability Chain、High-leverage Control Point、Guarantee Violation

下面的 CVE 不作为案例收藏，而用于说明如何把四类关系变成可验证的研究任务。

一、变化：什么旧前提已经不成立？

系统演进让旧防护失效

审查一次变更，通常会注意新增了什么危险逻辑。还可以进一步追问：这次变化，让哪些既有防护不再完整？

Spring4Shell（CVE-2022-22965）是一个典型案例。Spring 此前为修复 CVE-2010-1622，限制了数据绑定过程中对 Class 对象上某些属性的访问，阻断通往类加载器的已知路径。后来，JDK 9 引入模块系统，Class 增加了 getModule()，而模块对象又能返回类加载器。原先被阻断的直接路径之外，出现了一条旧防护没有覆盖的间接路径。(microsoft.com)

这里发生的变化，不一定在业务代码里。运行环境增加了一种对象关系，既有的数据绑定能力便可能触达原先不应开放的内部对象。当然，不能由此推导出“所有使用 JDK 9 的 Spring 应用都能被远程执行代码”。当时公开的利用场景还依赖受影响版本、相应数据绑定入口和传统 WAR 部署等条件；典型 Spring Boot 可执行 JAR 不受该条利用路径影响。(spring.io)

另一个方向是修复本身在演进中丢失。OpenSSH 的 regreSSHion（CVE-2024-6387）就是旧漏洞 CVE-2006-5051 的回归：此前修复过的信号处理竞态，在后续修改中重新出现，回归进入了 OpenSSH 8.5p1。(blog.qualys.com)

这两个案例分别提醒我：升级可能扩展原有代码的能力，重构也可能取消原有修复。仅仅知道“这个漏洞修过了”，不足以说明它所代表的安全要求会一直得到满足。

由此可以设计一种更具体的 AI 任务：先从历史修复中提取它试图阻断的能力，以及它依赖的前提，再结合当前变更重新检查。

假设一个字段过去只能由服务端生成，后来增加了用户导入入口；或者一个方法过去只供内部任务调用，后来被新接口暴露。敏感使用点可能没有任何修改，但输入可控性和路径可达性已经改变。

AI 不应只比较新增了哪些代码行，还应形成这样的调查结论：某个安全前提发生了变化，哪些入口因此可能到达哪些敏感操作，原有检查是否仍然有效。

这里不必一开始分析整个系统。可以围绕一次依赖升级、一个历史修复或一个新增入口，限定调查范围，再通过真实调用关系和受控实验确认。

值得寻找的，不只是新的危险代码，还有不再成立的旧前提。

从补丁反推不变量，再做 Variant Hunting

系统演进之外，历史补丁本身也是一张高价值的“安全假设地图”。一个补丁通常不会穷举所有同类路径，它只是在某个具体对象、函数或注册点上把已经被证明危险的能力收紧。真正值得继续问的是：这个补丁试图恢复的安全不变量，是否还存在别的实现没有被一起修掉？

Google Project Zero 在 2026 年 9 月披露的 CVE-2026-66804 就是一个很好的例子。该问题被描述为 CVE-2026-50343 “Dark Elevator”的不完整修复：Windows 中一个系统级 COM 注册仍指向缺失 DLL，低权限用户可以利用这个悬空注册影响高权限进程加载行为。(Project Zero)

这类研究不应停在“补丁 Diff 里还有没有漏改一行”。更系统的做法是先从补丁中抽象安全不变量：

历史漏洞
  ↓
补丁实际阻断了什么能力
  ↓
它依赖哪些对象 / 注册 / 路径 / 调用关系
  ↓
系统中还有哪些实现满足相同危险前提
  ↓
逐个验证这些 Variant 是否仍可达、可控、可利用

AI 很适合承担这里的“扩散”工作：从补丁和 Commit Message 中提取修复意图，枚举同类 API、同源代码、相邻组件、复制实现和旁路路径，再按可达性与影响排序。研究者则需要确认模型抽象出的不变量是否正确，以及所谓“相似实现”是否真的共享同一个安全前提。

这种方法比“给模型一批 CVE 让它学习漏洞长什么样”更可控，因为目标不是模仿漏洞表象，而是学习补丁为什么有效，以及这个安全条件是否在其他地方仍然缺失。

二、边界：两个组件理解的是同一件事吗？

下游信任了上游没有保证的条件

调用链可以说明 A 如何调用 B，却未必说明 B 为什么相信这次调用可以被允许。

Next.js 中间件授权绕过漏洞 CVE-2025-29927 暴露了这个问题。Next.js 使用内部请求头 x-middleware-subrequest 协调中间件与路由处理，避免递归执行。这个信号可以让后续处理跳过中间件，而受影响实现没有充分验证信号来源，外部请求也能影响这一控制逻辑。(nextjs.org)

如果应用将关键授权检查放在中间件中，跳过中间件就可能绕过这些检查。其影响与部署方式有关：官方确认部分自托管模式受到影响，而 Vercel 托管部署因路由架构不同，并未受到该漏洞影响。(nextjs.org)

从组件关系看，接收方需要的是“中间件确实已经执行”的可信保证，实际收到的却可能只是外部调用者能够影响的一段声明。

一个字段表达了安全结论，不等于这个字段能够证明安全结论。

类似问题也可以出现在响应方向。Apache HTTP Server 的 CVE-2024-38476 涉及后端应用输出被重新解释：恶意或可被利用的响应头，可能通过内部重定向触发本地处理器，造成信息泄露、SSRF 或本地脚本执行。后端返回的内容，并不总是被动展示的数据，也可能影响接收组件的内部处理。(httpd.apache.org)

这为跨系统分析提供了一个比“追踪所有输入输出”更集中的切口：上游实际提供了什么保证，下游又依赖什么条件？

假设上游只确认用户已经登录，下游却认为资源归属已经检查；生产者只保证消息来自某个服务，消费者却认为原始用户具有执行权限。缺少的那一项检查，究竟由谁负责？

可以让 AI 对“已认证”“已授权”“已检查”“来自内部”等信号做定向调查，追踪它们由谁生成、谁能修改、经过哪些边界，以及在哪个位置被验证。

输出不应只是一张调用图，而应包含每一段调用的安全契约：调用者保证什么，接收者相信什么，有哪些证据支持这种信任。

但没有在某个函数里看到检查，也不能直接认定存在漏洞。检查可能在上层统一执行，信号也可能由部署层可靠地隔离。需要沿真实路径确认缺口，而不是根据函数名和注释补出一条“看起来合理”的攻击链。

表示与解释：跨组件后输入变成了另一种东西

追踪一段数据从 A 到 B，还不够。还要追踪：A 和 B 是否把同一段数据解释成了同一种东西？

GitLab 的 CVE-2021-22205 提供了一个典型案例。GitLab Workhorse 在文件上传流程中会调用 ExifTool 处理图片元数据；漏洞链最终利用了 ExifTool 中 CVE-2021-22204 对 DjVu 文件 Annotation 数据的不安全处理。GitLab 官方 CVE 记录和 MITRE 都将 HackerOne #1154542 列为该漏洞的原始披露参考。(GitLab)(MITRE)

这个案例值得关注的不是单独的“文件上传”或“ExifTool RCE”，而是解释边界。上游流程可以根据文件名、扩展名或预期用途把输入视为图片，下游解析器却可能根据文件真实内容识别格式，并进入完全不同的 Parser。攻击者因此不一定需要突破“允许上传图片”这条表面规则，只需要让一个被上游接受的输入在下游获得另一种语义。

可以把这一类问题抽象为 Interpretation Gap / Parser Differential：

边界前的表示	边界后的真实解释
文件扩展名	Magic Bytes / 实际 Parser
HTTP Content-Type	服务端实际解码器
URL 字符串	Normalize / Decode 后的 URL
路径字符串	Canonicalize 后的文件路径
JSON 字段	反序列化后的对象与类型
网关看到的 HTTP 请求	Backend 重新解析后的请求
前端校验后的值	后端框架绑定后的真实字段

这里的共同风险是：安全判断基于表示 A，敏感操作却基于解释 B。 如果 A 与 B 之间不是严格的一一映射，攻击者就可能寻找一个“在 A 看来安全、在 B 看来危险”的输入。

对应的 AI 调查不应只做普通 Source-to-Sink 数据流，而要显式记录每个边界的解释函数：

原始输入
  ↓
组件 A 如何分类 / Decode / Normalize
  ↓
安全判断依据什么表示
  ↓
跨组件传递
  ↓
组件 B 如何重新 Parse / Bind / Canonicalize
  ↓
敏感操作实际消费什么语义

然后针对同一输入构造差分：改变编码、扩展名、大小写、分隔符、重复字段、嵌套结构、协议边界或文件内容，观察两个组件的解释是否发生分叉。

这种方法也适用于 Request Smuggling、路径穿越、URL Parser Differential、反序列化和参数污染等问题，但不能看到“两个 Parser”就直接判定漏洞。必须继续证明：解释差异确实跨过了某项安全检查，并且下游解释能够到达敏感行为。

WordPress 的 CVE-2026-65640 又提供了一个相近但更适合系统化搜索的实例。WordPress 官方公告确认，pwn.ai 团队报告了一个在使用 Imagick 与 Ghostscript 的站点上、需要 upload_files 能力（默认 Author+）的恶意文件上传 RCE。公开资料可以确认发现归属和利用前提，但不足以判断该漏洞具体由人还是 Agent、以及自动化程度，因此不应把它表述为“AI 自动发现的 0day”。(WordPress)(GitHub Advisory)

这个案例可以把 Interpretation Gap 进一步写成一个差集问题。设上游安全校验允许的语义集合为 A，下游通用 Parser / Processor 实际能够解释的集合为 B，值得重点寻找的是：

能够通过 A 的校验，却在 B 中获得额外危险语义的输入。

因此可以定向枚举所有“安全校验后继续交给更强解释器”的边界，例如：

Upload Validation  → Image / Document Processor
MIME Validation    → Parser
Archive Validation → Decompressor
URL Validation     → HTTP Client
Template Validation→ Renderer
Document Validation→ Converter
Source Validation  → Compiler / Interpreter

AI 不只需要比较扩展名和 Magic Bytes，而应提取上游校验实际约束的属性、下游解释器真正使用的属性，以及下游额外拥有的 Delegate、外部进程、网络、文件系统或代码执行能力。下游解释能力越强于上游校验表达能力，这个边界越值得优先调查。

因此，跨组件分析除了问“上游保证了什么、下游相信什么”，还应该再问一句：

安全检查看到的对象，和最终执行组件看到的对象，真的是同一个语义对象吗？

三、状态：安全属性什么时候发生变化？

认证前状态：身份尚未成立，可信状态已经被创建

认证系统还值得单独检查一个时间顺序问题：在身份被证明之前，系统已经创建、写入或返回了哪些后续会被信任的状态？

CVE-2026-41940 是一个真实案例。cPanel 官方将其描述为 cPanel & WHM Session Management Layer 的认证漏洞；NVD 将其归为认证绕过，CISA KEV 记录表明该漏洞曾被实际利用。新加坡 CSA 的公开说明进一步指出，来自 Authorization Header 的用户可控输入在认证发生之前被写入服务端 Session File，且缺少适当 Sanitization，最终可能让未认证远程攻击者获得管理访问。(cPanel)(NVD)(CSA Singapore)

这个根因可以抽象为 Pre-auth State Creation：

未认证输入
    ↓
创建 / 修改服务器状态
    ↓
认证流程继续
    ↓
后续组件把该状态当成可信身份上下文
    ↓
权限提升或认证绕过

对应的 AI 调查不应只寻找“认证函数有没有漏洞”，而应围绕认证边界前后的状态生命周期提问：

• Login、OAuth、SSO、Password Reset、MFA 之前会创建哪些 Session、Cookie、Nonce、Cache、临时账号或服务器文件？
• 这些状态中哪些字段来自未认证输入？
• 写入时是否已经绑定可信主体，还是只在后续阶段补身份？
• 认证成功后是否复用了认证前创建的对象，而没有重新生成或重新验证关键字段？
• 下游授权逻辑看到的是“认证流程生成的状态”，还是能够被认证前输入污染的状态？

这类问题与 Session Fixation 有联系，但研究范围可以更广：临时身份、设备绑定、OAuth State、密码重置上下文、风控标签、租户选择和预授权缓存，都可能在身份建立前产生。

这里的核心安全不变量是：

认证前允许创建的状态，不应仅因为认证流程随后成功，就自动升级成可信授权状态。

如果业务必须复用认证前状态，认证完成时应明确重新绑定主体、校验来源与完整性，并丢弃不应该跨越认证边界的用户可控字段。

验证链不是一个布尔值：多个弱检查的交集

复杂认证和安全协议通常不是一个 verify() 决定成败，而是解析、算法选择、密钥解析、签名、Issuer、Audience、身份映射等多个阶段共同建立信任。真正值得寻找的漏洞，有时不是某一步完全没有检查，而是多个看似局部合理的弱点组合后，使整条验证链失去原本要证明的安全性质。

SharePoint 的 CVE-2026-55040 是一个很好的案例。Rapid7 对 SharePoint Server Subscription Edition 的反编译分析指出，其 S2S 认证使用嵌套 JWT：外层 Token 携带用户身份，内层 Actor Token 表示调用应用，后者本应由可信证书签名。Rapid7 将根因归纳为 JWT 验证流水线中的四个独立弱点组合，最终允许未认证攻击者伪造可接受的 Token 并冒充 SharePoint 用户。(Rapid7)

这个案例适合抽象成 Validation Chain Composition：

Parse
  ↓
Algorithm Policy
  ↓
Key Resolution
  ↓
Cryptographic Verification
  ↓
Issuer / Audience / Trust Validation
  ↓
Identity Mapping
  ↓
Authorization

AI 审计时不应只分别问“有没有验签”“有没有检查 Issuer”，还应该为每一步记录：

• 这一步准备证明什么安全事实？
• 它接受哪些输入和 fallback？
• 失败是否一定终止，还是会进入另一条兼容路径？
• 上一步输出是否被下一步当成了比实际更强的保证？
• 是否存在一组输入，让每个局部检查都走到可接受分支，但最终没有任何一步真正证明完整身份链？

这与“判断成功意味着什么”相关，但关注点不同：这里研究的是多个 Validator 之间的组合语义。单独看每个函数可能都存在检查，漏洞只在把完整 Pipeline 串起来后出现。

把四类关系交给 Agent 搜索

复杂闭源目标：先建立可查询的系统模型

CVE-2026-55040 还有一层与 AI 漏洞挖掘直接相关的价值。Rapid7 披露，这次 SharePoint 0day 项目分两轮研究：2026 年 1 月的第一轮没有得到可用于 Exploit Chain 的发现；3 月第二轮最终得到由两个漏洞组成的未认证 RCE 链。整个项目包含 24 个 Agent 工作日、96 个 Session、256 个 Prompt 和约 8 万次 Agent Tool Call，同时仍包含人工代码审查和逆向工程。(Rapid7)

这个数据不能简单解释成“更多 Tool Call 就能找到漏洞”。更值得注意的是第一次失败后，模型、工作流和研究方法共同发生了变化。对于 SharePoint 这种闭源、大规模、反编译后的代码库，Agent 首先需要把碎片化符号、继承关系、协议状态和跨模块调用逐渐变成可查询的系统模型，再在其上提出假设。

因此复杂目标的研究资产不只是最终漏洞，还包括：

失败 Sprint → Dead-End / Trace → Harness 与 Workflow 调整 → 第二轮重新搜索

这与前面的 Dead-End Memory、Security Skill 和 Eval 形成闭环：失败不是简单增加 Token，而应该改变下一轮搜索空间、上下文组织或验证策略。

Rapid7 随后披露第二个漏洞 CVE-2026-63520：Business Connectivity Services 中的不安全 .NET 类型实例化问题。两个漏洞分别是认证绕过和认证后的 RCE，组合后成为未认证 RCE。这再次说明单点严重度和前置条件不能代替完整 Capability Chain 分析。(Rapid7)

判断与含义的关系：检查通过，却没有证明该证明的事情

有些安全检查并没有被绕过。它被正常执行，返回成功，但这个成功没有对应真实的安全保证。

Java 的 “Psychic Signatures”（CVE-2022-21449）就是这样的案例。受影响的 ECDSA 验签实现遗漏了必要的参数检查，可能将签名参数 r、s 均为零的退化签名接受为有效签名。这是实现缺陷，并不是 ECDSA 算法本身被破解。(neilmadden.blog)

验签原本要证明消息由对应私钥持有者签署。程序返回成功，却没有完成这一证明。

libssh 的 CVE-2018-10933 则表现为认证状态的问题：受影响的服务端在接收到客户端提供的认证成功消息后，可能在没有凭证的情况下完成认证。“收到了认证成功消息”，被错误地等同于“服务端已经完成认证”。(libssh.org)

这些案例提供的启示，不是再增加一条“检查验签函数”的规则，而是重新审视成功条件的含义。

假设业务要求至少一名有效审批人通过，代码却只检查“所有审批人是否都已通过”。如果审批人列表允许为空，程序条件可能成立，但实际没有发生任何有效审批。

又如，业务要求多个独立主体确认，实现却只统计记录数量。同一个主体产生的重复记录，可能满足数量要求，却没有满足职责分离要求。

这些是假设场景，具体规则需要由业务契约确认。对应的 AI 任务可以写得很明确：提取关键判断的通过条件，寻找“条件成立，但安全要求未满足”的反例。

AI 可以辅助定位授权谓词、解释它依赖的状态；属性测试或约束求解工具可以辅助探索零值、空集合、重复主体、默认身份和过时数据等边界。

更重要的是，反例必须能够通过真实流程到达。直接修改数据库，制造一个正常系统不可能产生的状态，不能自动算作有效漏洞。模型理解错了业务规则，也会产生看似严密、实际上没有意义的反例。

需要审查的，不只是系统有没有检查，还包括检查成功究竟意味着什么。

上下文复用：安全相关的信息在哪里丢失

两个操作看起来相似，不代表它们可以共享同一个结果。

libcurl 的 CVE-2022-27782 涉及连接过度复用。libcurl 会保留已建立的连接供后续传输使用，但受影响实现的匹配判断遗漏了若干 TLS 和 SSH 安全配置。因此，即使后续传输改变了本应阻止复用的选项，旧连接仍可能被复用。遗漏的配置包括证书吊销列表文件、部分 TLS 认证参数和 SSH 密钥文件等。(curl.se)

这里不是“连接池本身不安全”，而是复用条件没有完整表达连接的安全上下文。两个本应被区别对待的配置，被系统判断成了可以复用同一个连接。

curl 的另一个漏洞 CVE-2024-0853 涉及验证状态没有正确约束会话复用。受影响实现即使在 OCSP 装订校验失败后，仍可能缓存对应的 TLS 会话 ID；后续对同一主机的传输若复用该会话，就可能跳过相关状态检查。官方将这一问题限定在使用 OpenSSL、TLS 1.2 的相应实现条件下。(curl.se)

前一个案例遗漏的是配置差异，后一个案例没有正确保留验证失败带来的约束。它们共同指向一个问题：系统复用的究竟只是一个对象，还是连同它成立所需的安全条件一起复用？

这个切口可以延伸到业务系统。

假设两个租户拥有相同的局部对象编号，查询时正确区分租户，缓存时却只保留对象编号。又或者审批绑定了任务编号，但任务内容可以在审批后修改，执行时仍然复用原审批结果。

需要寻找的不是密码学意义上的碰撞，而是业务表示省略了本应影响安全决策的信息。

可以让 AI 先梳理一个结果实际依赖哪些条件，再检查缓存键、去重键、会话标识和授权凭据保留了哪些条件，随后构造两个只在关键安全维度上不同的上下文，验证它们是否被错误地视为等价。

这不意味着所有标识都要附带所有字段。不可变对象、版本绑定、重新授权或其他有效机制，都可能正确保留相关约束。

调查必须证明三件事：被省略的信息确实应该改变安全结果，系统确实发生了错误复用，而且没有其他控制补上这项差异。

四、组合：局部安全为什么组合后仍然不安全？

缺陷与正常能力组合成完整利用链

一个漏洞需要认证，不代表外部攻击者一定无法满足这个条件。需要继续追问：系统里是否存在另一条路径，能够提供它所需的访问能力？

Exchange 的 ProxyLogon 利用链提供了一个明确案例。DEVCORE 公布的链路由两个关键漏洞组成：CVE-2021-26855 是认证前 SSRF，可进一步造成认证绕过；CVE-2021-27065 是认证后的任意文件写入，可在完整链路中推进到远程代码执行。(devco.re)

微软的技术说明同样指出，CVE-2021-27065 所需的认证条件，可以通过 CVE-2021-26855 取得，并不一定要预先掌握合法管理员凭证。(microsoft.com)

如果只独立审查后一个问题，调查可能停留在“需要认证才能利用”。放回完整系统，前一段漏洞恰好提供了后一段的前提，两者可以衔接成从未认证入口到代码执行的路径。(devco.re)

这里不能把单点问题统称为“小问题”，也不能说各个组件单独都安全。它说明的是：局部利用条件并不是完整风险判断，前一步获得的能力可能改变后一步的可利用性。

由此可以将每个发现记录成两个部分：利用它需要什么条件，利用之后能够获得什么能力。

但仅有“身份”“文件写入”“内部访问”等标签还不够。身份属于哪个权限域，文件由哪个进程读取，资源属于哪个租户，能力能保持多久，都可能决定下一步是否真的可行。

可以让 AI 围绕一个已经证实的能力做有限扩展，寻找哪些后续操作的前提因此得到满足。每扩展一步，都需要重新核实条件，而不是一次性生成一张很长的攻击图。

这一思路也可以用于正常业务操作的组合。假设任务可以先被批准，再修改执行目标，而执行阶段没有重新确认授权，那么“提交”“审批”“修改”“执行”这些局部动作都可能符合各自接口的规则，整体却没有满足“执行内容必须经过有效批准”的要求。

这类调查需要观察完整操作序列。身份变化、异步任务、并发交错、重试和补偿，都可以成为需要纳入验证的条件。

一条成立的风险链，不是几个可疑点被连在一起，而是每一步都真实提供了下一步需要的能力，并最终突破了明确的安全边界。

近期 Hacktron AI 披露的 OpenAI Bug Bounty 案例进一步说明了跨系统组合的价值。公开报道显示，研究者先利用 OpenAI 社区论坛所依赖的软件链路中的文件处理缺陷获得服务器侧执行能力，再利用另一个账户接管问题进入 OpenAI 员工的 ChatGPT / Codex 账户；OpenAI 随后修复了相关问题。公开信息同时表明，第一阶段涉及 Discourse、ImageMagick 与 libheif 等第三方组件，第二阶段则跨入 OpenAI 自身账户与代码访问边界。(TechCrunch)

这个案例的价值不在“AI 帮助攻击了 AI 公司”，而在于它提醒研究系统不要把 Repository、产品或供应商当成天然边界。现实攻击链经常是：

第三方组件缺陷
   ↓
获得某个系统内能力
   ↓
利用系统间身份 / Token / Session / 集成关系
   ↓
进入另一个产品或权限域
   ↓
继续放大能力

因此 Cross-system Vulnerability Chaining 可以成为一类独立研究任务。AI 不只追踪“这个服务调用了哪个服务”，还应该维护 Capability Graph：每个已验证问题能提供什么身份、网络位置、文件访问、Token、控制面能力或持久化状态；这些能力又能满足哪些其他组件的前置条件。

这里尤其值得优先调查第三方 SaaS、论坛、工单、CI/CD、SSO、客服后台、浏览器扩展、机器人与代码托管平台等“外围系统”。它们单独看可能不属于核心生产系统，却经常持有进入核心系统所需的身份与信任关系。

从安全承诺反推攻击面：新系统里的老漏洞

AI 基础设施不一定需要“AI 特有漏洞”才能破坏其核心安全目标。Apple Private Cloud Compute 的 CVE-2026-20685 是一个很好的例子：研究者 Drinor Selmanaj 在 Apple 提供的 Virtual Research Environment 中发现，PCC 节点启动阶段的 darwin-init 在提取 Cryptex 归档时存在路径穿越，可在 root 权限下把文件写出预期目录。Apple 最终将其修复于 PCC 5E290.3，并支付 15 万美元漏洞赏金。(Sentry)

真正值得复用的不是“再检查一次 ../”，而是研究者选择攻击面的方式。PCC 对外强调 Stateless、Attested、Sealed Observability 等安全与隐私保证。研究可以从这些承诺反向追问：

为了让这个保证成立，哪些组件、状态和时间窗口必须始终满足什么条件？

在 PCC 中，darwin-init 是第一个 userspace 进程，以 root 身份完成节点 Provisioning，而稳态安全服务尚未全部启动。它恰好位于一个高杠杆窗口：权限已经很高，安全不变量还没有完全建立。 一个传统 Archive Extraction 缺陷因此能够影响远比“任意文件写”更大的系统保证。

这种方法可以抽象成 Guarantee-driven Attack Surface Mapping：

系统公开/设计的安全保证
        ↓
保证依赖的安全不变量
        ↓
谁负责建立这个不变量
        ↓
建立之前 / 转换期间 / 恢复期间有哪些窗口
        ↓
这些组件拥有什么权限与可写状态
        ↓
传统漏洞 Primitive 能否破坏该不变量

尤其应该优先检查 Bootstrap、Provisioning、Upgrade、Recovery、Migration、Failover 等状态转换阶段。稳态系统可能已经有完整 Sandbox、Attestation、Network Policy 和审计，但建立这些控制的组件本身往往拥有更高权限，而且运行在控制尚未完全生效的窗口。

因此“新系统里的老漏洞”并不矛盾。Path Traversal、TOCTOU、Injection、Unsafe Deserialization、权限继承错误等传统 Primitive，只要出现在新的高权限控制点，就可能突破新的安全保证。研究重点应该从“这个漏洞类型新不新”，转向：

这个 Primitive 出现在什么信任位置，它能够破坏哪个系统级不变量？

不要平均搜索攻击面：优先寻找高杠杆控制点

攻击面上的节点价值并不相同。普通用户功能、运营后台、内部管理 API、跨租户 Control Plane 和共享基础设施一旦失守，影响范围可能完全不同。漏洞挖掘系统如果平均分配搜索预算，很容易在大量低影响接口上消耗算力，却忽略少数能够控制大量资产、身份或下游系统的节点。

Sam Curry 等研究者公开的多个案例提供了这种研究直觉：ClubWPT Gold 的核心 Back Office、Subaru STARLINK 的车辆与客户管理后台、Kia 的远程车辆服务，以及被大量航空公司和酒店奖励计划依赖的 Points.com，都体现了高权限控制面或共享后端一旦出现边界问题，影响可能跨越单一用户或单一产品。(samcurry.net)

这不意味着“后台一定比前台更容易有漏洞”，也不能根据系统名称直接推断严重度。更合适的做法，是在 Attack Surface Mapping 阶段为节点增加一组搜索优先级信号：

• Privilege：该节点能够执行多高权限的动作。
• Reach：一次操作能够影响多少用户、租户、设备或资源。
• Dependency：有多少产品或下游系统依赖它。
• Trust Boundary：它是否负责身份转换、授权、租户隔离或跨系统信任。
• External Reachability：攻击者需要什么身份和网络位置才能接近它。

这些信号可以组合成搜索排序，但不应机械计算成“漏洞严重度”。它们回答的是哪里值得优先投入研究预算，真正的风险仍需要具体漏洞、利用条件和业务影响来证明。

Repository Mapping 因此不应该只输出文件、路由和调用关系，还应尝试识别 Control Plane、Back Office、Admin API、身份服务、共享中间层、批处理平台和多租户基础设施。一个入口代码量很少，也可能因为它控制大量下游能力而比复杂业务模块更值得深挖。

这也提供了一个从 Where 开始的研究策略：

先找到系统中“一个错误决定能够影响很多东西”的位置，再调查这些位置依赖了哪些安全假设。

把漏洞挖掘变成受预算约束的搜索系统

前面的研究切口回答了“值得去哪里找”。真正把它做成 Agent 系统，还要回答另一个问题：面对一个大型仓库，怎样分配有限的搜索预算？

漏洞发现不是把全部代码一次性塞给最强模型。仓库中的入口、数据流、权限边界、历史变更和敏感操作会组合出大量候选路径，Agent 必须不断决定：先调查哪个区域，同时保留多少假设，哪些路径值得继续深入，什么证据足以放弃或确认一个假设。

因此可以把 AI 漏洞挖掘抽象成：

搜索空间构建 × 假设生成 × 搜索策略 × 模型能力 × Harness/工具 × 验证能力 × 计算预算

模型能力只是其中一项。Repository Mapping、攻击面识别、调用关系恢复、历史变更检索、候选排序、动态验证和去重共同决定模型实际看到什么，以及算力花在哪里。

一种实用策略是把 Breadth 与 Depth 分开分配。第一阶段用较低成本的模型或 Agent 并行覆盖入口、边界和多种攻击假设，优先扩大搜索宽度；第二阶段根据可达性、影响、证据强度和新颖性筛选候选，再把更强模型、动态环境和更多 Token 投到少量高价值路径上。对已经出现反证、重复根因或长期没有新增证据的路径，应及时停止，而不是因为已经投入成本继续搜索。

Aikido 曾在自建的 89 个已知漏洞私有 Benchmark 上比较 Aikido、Claude Security + Mythos 和 Codex Security，并报告不同的发现率与运行成本。这个结果来自厂商自己设计和执行的单一 Benchmark，不能据此判断产品整体优劣；更值得关注的是它暴露出的工程变量：在模型接近时，搜索宽度、深度、资源调度和验证方式会直接影响最终召回与成本。(aikido.dev)

计算预算也应该显式进入策略。可以按代码规模、语言和框架复杂度、外部入口数量、敏感 Sink、历史漏洞密度以及跨服务关系，为任务分配初始预算；运行过程中再根据新证据动态调整。简单路径用便宜模型快速排除，复杂调用链和高影响候选再升级模型。预算耗尽时，系统应输出“哪些假设已验证、哪些被否定、哪些仍缺证据”，而不是强行给出漏洞结论。

这也意味着 Harness 的职责不只是安全执行工具，还包括管理搜索：保存候选假设和证据，控制并发与模型档位，识别重复探索，设置停止条件，把动态验证结果重新送回搜索过程。模型负责提出和更新假设，Harness 负责让搜索过程可控、可恢复、可度量。

最终差异化不只是“谁的模型更聪明”，而是：

谁能更快构建高质量搜索空间，把更多预算投到真正值得深入的路径，并用更低成本获得足够强的验证证据。

人提出好问题，AI 扩大搜索并降低验证成本

搜索系统决定算力怎样分配，一线漏洞挖掘还需要回答：人和 AI 各自最适合做什么？

漏洞猎手 trieulieuf9 在《How I use AI for bug hunting》中记录了几种实际用法。它们的价值不在某个模型或 Prompt，而在于把 AI 放进了真实 Hunting 工作流：扩展测试思路、生成小工具、自动化侦察，以及快速验证已经形成的研究假设。

用 AI 扩展攻击假设，而不是替代判断

作者会把已有测试用例和约 400 行目标情报交给模型，限定访问控制类漏洞，要求尽可能穷举新的测试组合。输出中大部分并不新颖，甚至不适用于目标，但少数反常组合会提示此前没有注意到的攻击面。

这说明大规模 Brainstorming 的价值不一定是“直接给出漏洞”，而是提高假设生成的宽度。对成熟研究者，它可以把已有经验重新组合；对经验较少的人，它可以先生成一份 Seed Todo List，帮助建立“还能测试什么”的搜索起点。

如果没有自己的 Checklist 和 Intel，也可以从公开文档开始。与其一次把全部资料交给模型，不如按单篇文档、单类漏洞或单个业务域分别生成候选，再统一去重和排序。这样更容易知道每个假设来自什么证据，也减少大上下文中不同业务语义互相污染。

但“模型提出了一个有趣组合”仍然只是候选。研究者需要判断它是否符合目标真实业务、是否已有控制，以及值得投入多少验证成本。

把重复动作持续沉淀成工具

作者最认可的 AI 用法不是全自动漏洞挖掘，而是写 Utility Tools。过去只有具备开发能力的研究者能快速写 Burp Extension、编辑器命令和 Python 脚本；代码生成模型降低了这种工具化的门槛。

原文给出的个人经验是：一个动作如果反复执行且单次已经需要十几秒，就会考虑把它自动化。这个“15 秒”不是通用阈值，更值得保留的是背后的判断：

高频、机械、输入输出明确、结果可验证的操作，应逐渐从人工动作沉淀成工具。

URL 清洗、请求重放、Header 变换、结果 Diff、字段枚举、Token 获取、格式转换和证据整理，都属于典型候选。单次节省可能很小，但工具会被后续所有 Hunting 复用。

因此一次漏洞研究除了产出漏洞，还可以产出新的脚本、词表、规则、测试模板和 Skill。长期看，研究者积累的不只是漏洞数量，而是一套越来越快的个人或团队 Toolchain。

AI 生成专项分析器：先制造新的“眼睛”

AI 写小工具的价值还可以再往前走一步。Trail of Bits 在 2026 年 9 月总结其审计实践时提到，在正式代码审计之前，他们让 Agent 为 Miden VM 构建了 LSP、反编译器、静态分析引擎以及 Lean 形式化模型；这些工具不是最终报告里的漏洞，而是后续审计得以深入的基础设施。(Trail of Bits)

这提供了另一种思路：AI 的优势不只是替代人读更多代码，还可以快速制造过去不值得人工投入的专项分析能力。

很多难题之所以长期没有被系统化检查，并不是没有安全价值，而是工具建设成本太高。例如：

• 一个框架的反射和动态路由让调用链恢复困难。
• 一个私有协议缺少可用 Parser 和状态机模型。
• 一套业务 DSL 没有现成静态分析器。
• 一个闭源或反编译目标需要先恢复类型、继承与调用关系。
• 一个新 VM / Runtime 缺少调试、反编译和形式化工具。

过去研究者可能因为“先造工具就要花几个月”而放弃。代码生成 Agent 改变的是这个经济模型：可以先让多个 Agent 并行构建 Parser、LSP、Decompiler、Call Graph、Query Engine、Fuzzer Harness、Diff 工具或形式化模型，再让安全研究建立在这些工具之上。

因此工具化可以分成两层：

层次	目标
Utility Tooling	把重复手工动作自动化，提高执行效率
Research Tooling	为某类过去难以观察的问题创造新的分析能力

第二层更可能带来真正差异化。它把“模型能不能直接找到漏洞”改成另一个问题：

能不能先让 AI 为这个目标造出此前不存在的分析工具，再借这些工具打开新的搜索空间？

当然，AI 生成的分析器本身也可能有 Bug。它们必须用已知样本、负样本、单元测试和人工抽查验证，否则错误的 Call Graph、错误的 Parser 或不完整的形式化模型只会让后续研究建立在错误基础上。

自动化 Recon 的价值与代价都要计算

作者也尝试让本地 Claude 读取目标 API 文档，收集字段词表，使用授权测试账户对不同资源探测可编辑字段，并构建“角色 × 功能”的权限矩阵。

在其公开案例中，这种方法帮助发现了两个访问控制相关问题：一个对象存在未记录但可编辑的 parent_id，使一个用户创建的对象能够关联到另一用户的父对象；另一个对象虽然某角色没有删除权限，却暴露了可编辑的 deleted_at 字段，从而可能通过修改字段产生等价删除效果。这些是作者对具体目标的经验案例，不能推导出相同字段在其他系统中也构成漏洞。

更重要的是作者对全自动方式的负面反馈：配置 Agent、准备凭证、编写 Prompt、等待长时间执行都会消耗成本；即使最终工作，也不一定比“人形成假设、机器批量验证”更高效，更不意味着研究者自身能力同步提高。

因此自动化程度本身不是目标。应该比较：

• 自动化准备需要多少人工时间。
• 执行需要多少模型、工具和环境成本。
• 相比手工方法增加了多少覆盖。
• 发现是否真正带来新的独立根因。
• 自动化产物能否被下一次任务复用。

如果一次自动化只替代少量低频操作，却引入大量配置和维护，它可能没有正收益。

用 AI 快速验证已经形成的研究想法

另一类高价值场景是“人已经有一个安全假设，但验证范围太大”。

例如研究者发现某个 Accept: application/json 行为后，会自然追问：同一技巧是否在目标其他 URL 上成立？真正耗时的工作变成收集 URL、合并公开历史数据、浏览器 Sitemap、Spider、JavaScript 或移动端端点，随后去重，再批量发送带特定 Header 的请求。

这些步骤大多不是安全判断本身。AI 可以生成收集和去重脚本、封装 ffuf 等已有工具、整理输出，甚至在授权测试环境中自动登录并取得短期 Token。研究者则集中判断哪些响应差异意味着新的攻击面，以及下一轮应该验证什么。

这种分工可以概括为：

角色	更适合承担的工作
人	理解目标、提出攻击假设、识别异常、判断业务影响、决定新方向
AI	阅读资料、组合扩展、生成脚本、Recon、批量执行、结果归纳
Harness	权限、凭证边界、状态、并发、预算、审计、证据和停止条件

边界不是固定的。随着 Eval、工具和验证能力成熟，一部分原本需要人的工作可以逐渐下沉给 Agent；但下沉依据应该是可验证性和风险，而不是“模型已经能生成看起来合理的答案”。

失败路径也是研究资产

真实 Hunting 中，大多数假设最终不会成为漏洞。失败路径如果只留在会话历史里，下一次 Agent 很容易重新走一遍；如果只记录“没发现问题”，又丢失了最有价值的信息：为什么这个假设不成立。

一个 Dead End 至少可以保存：

假设：某入口可能绕过资源归属检查
已验证证据：入口可达，资源 ID 可控
失败原因：统一授权层在进入业务函数前强制校验 tenant_id
不成立前提：攻击者无法控制授权层使用的 tenant_id
重新检查条件：授权中间件变化、新增绕过中间件的入口、身份上下文来源变化

这样失败结果同时承担四种作用：

• 搜索去重：避免不同 Agent 在相同证据下反复调查同一路径。
• 负样本：进入 Eval，检查系统是否会把已证伪路径再次误报为漏洞。
• 预算优化：识别长期低收益的方向，把计算资源转向更有希望的假设。
• 变化触发器：当失败所依赖的安全前提发生变化时，重新打开历史假设。

因此研究系统不应只有 Finding Database，还应该有 Hypothesis / Dead-End Memory。成功发现告诉系统“什么模式值得继续找”，高质量失败则告诉系统“什么条件已经被证明不成立，以及什么时候这个结论可能失效”。

每次 Hunting 都应该让下一次更快

把这些实践与 Agent 持续优化放在一起，可以形成一个更长期的闭环：

人的研究经验
    ↓
攻击假设 / Checklist / Intel
    ↓
AI 扩展候选与生成工具
    ↓
授权环境中的批量验证
    ↓
人工确认新根因
    ↓
脚本 / Skill / Eval / 规则 / 词表沉淀
    ↓
下一轮更快、更广、更准确

真正值得复利的不是某次 Prompt，而是专家判断被不断结构化。成功的测试可以进入回归集，误报可以变成负样本，重复操作可以进入工具链，新攻击面可以进入 Checklist，目标特有知识可以进入 Intel。

这样，AI 漏洞挖掘才从“用模型帮我找一次漏洞”，逐渐变成“每次研究都在训练下一次研究所使用的系统”。

发现能力不是模型单变量

专家、模型、Harness 与工具共同决定发现能力

AI 漏洞研究不能只比较模型。ret2p.lt 作者公开描述的 CVE-2026-28956 “Requiem” 是一个有代表性的个人案例：作者称该 libJPEGXL 漏洞由 Claude Code、少量修改后的 Jackalope 和 ImageIO Fuzzer 共同发现。这个案例能够证明的是一种实际研究组合，而不是单独证明某个模型具有自主发现同类 0day 的稳定能力。(ret2p.lt)

更合理的能力表达是：

Research Capability = Researcher Expertise × Model × Context × Harness × Tools × Validation

领域专家决定问题选择、异常是否值得追和结果意味着什么；模型扩大阅读、假设与推理规模；Context 提供历史漏洞、架构和目标知识；Harness 管理搜索、状态与预算；Fuzzer、Debugger、Browser 和静态分析器提供模型无法仅靠文本推理获得的真实信号；Validation 最终把候选变成可复核发现。

这也解释了为什么同一个模型在不同研究者手中差异可能很大。AI 可以降低执行门槛，却不会自动补齐领域模型、实验设计和证据纪律。评估一个 AI 漏洞挖掘系统时，应冻结或至少记录上述变量，而不是把所有提升都归因于“换了更强模型”。

把专家经验变成可执行的 Security Skill

开放式探索负责寻找未知问题，但成熟的漏洞发现系统不能只依赖模型临场发挥。Mandiant 在 2026 年公开的 Agentic Vulnerability Discovery Harness（AVDH）提供了另一条重要路径：把一线安全专家长期积累的经验提炼成模块化规则，并在分析过程中按目标技术栈和漏洞类型选择性注入。

其知识体系按软件 Domain 组织，再分为 Language、Framework、Vulnerability 三类规则。语言和框架规则贯穿分析过程，帮助 Agent 理解入口定义方式、技术特有攻击面和威胁建模上下文；漏洞规则主要用于后段，规定某类问题应怎样发现、验证和评级。这与 Skill Engineering 的思想接近：不是把所有经验堆进一个巨大 Prompt，而是让经过验证的专家方法按需加载。

这种结构补充了纯探索式方法的不足：

• Exploration 扩大未知问题和异常组合的搜索空间。
• Security Skill 系统覆盖已经掌握的专家经验，减少已知模式漏报。
• Context 提供资产、SBOM、架构、威胁情报和目标代码等当前环境事实。
• Eval 检查 Skill 和 Prompt 更新究竟提高了召回还是引入回归。

专家经验也不应只写成“查找 SQL 注入”这样的漏洞名称。更有价值的是保留发现方法：入口通常如何定义、哪些框架行为会改变可达性、数据经过哪些 Sanitizer 后仍值得追踪、什么证据才能确认漏洞、哪些条件会推翻假设。这样经验才能被 Agent 执行和验证。

Mandiant 报告 AVDH 已在内部使用约十个月，并披露在一次涉及被盗企业代码仓库的事件响应中，两天发现超过 100 个经其确认的 Critical 漏洞；其还报告在数千万行代码环境运行数千条 Pipeline，并产生 12 个已分配 CVE。这些是 Google/Mandiant 对自身系统的公开结果，适合作为工程案例，而不是独立 Benchmark 或对其他系统能力的比较结论。(Google Cloud)

更值得复用的是闭环：专家知识进入 Skill → Agent 在真实代码中执行 → 新发现和漏报进入评测 → 专家更新规则 → 新版本重新跑 Benchmark。 专家的价值因此不只存在于一次人工 Review 中，而是逐渐成为组织可以重复调用的发现能力。

从研究切口到可验证的发现能力

这些案例证明相关问题确实发生过，但它们本身不能证明某个 AI 系统已经具备稳定发现能力。

历史评审、漏洞工单、代码差异和运行日志，是提供证据的材料；反射还原、框架建模和跨服务关联，是完成调查所需的能力；动态测试、属性测试和形式化方法，则可以帮助求证。它们应当服务于具体假设，而不是全部堆进上下文，期待模型自行给出可靠结论。

对于一项发现，我希望至少能追溯清楚：它声称哪项安全要求被破坏，关键前提分别由什么证据支持，如何在保留真实安全控制的条件下复现，以及什么结果能够推翻这个假设。

发现器和验证器可以分开，但不是让两个模型互相投票。验证必须落到代码、配置、状态和执行结果上。证据不足，应保留为待确认；为了让复现成功而移除关键鉴权，则改变了被研究的问题。

评估这些路线，也不能只看告警数量或旧 CVE 的复现成功率。我更关心的是：在合理控制模型、预算和人工投入后，它能否带来现有流程没有找到的、可复现的新根因。

一种对照可以让通用审计与专项方法拿到相同资料，比较发现策略的增量；另一种对照再加入跨服务实现或历史变更，观察新增上下文的价值。安全实现、修复版本和不满足利用条件的场景，也应该进入测试，而不是只准备能够成功的样本。

计数应按独立根因去重，并记录人工确认耗时。同一问题命中几十个接口，可能意味着影响面很大，但不意味着获得了几十种新的发现能力。

起步也不必追求完整。可以先选一次依赖升级、一种广泛使用的 SDK、一个关键授权判断，或者一类缓存和会话机制，把证据收集、假设生成与验证做通，再扩大范围。

回到最初的问题：模型能力接近之后，差异化从哪里来？

我的判断是，除了模型和工具本身，还在于能否把过去分散处理的信息放回同一个安全问题里。变化后的环境是否仍满足旧防护的前提，下游相信的条件是否由上游真正保证，检查通过是否意味着要求成立，复用是否保留了必要上下文，以及一个局部能力能否改变后续操作的利用条件。

这不是替代危险代码分析，而是让调查不再停在危险代码那里。

下一次打开一个仓库，除了问“这里有没有漏洞”，还可以从一个更具体的问题开始：

这个系统认为什么事情已经被保证了？沿着真实执行路径看，它真的被保证了吗？