文章总结： PortSwigger研究总监JamesKettle通过构建自主研究系统HTTPTerminator，让AI从RFC文档中提取灵感生成攻击向量，在3万个授权网站上验证，确认约700个漏洞，包括多个零日如CVE-2026-63078，并发现新攻击类别shared-parserconfusion。实验表明AI能自主发明新技术，但最重大发现需人机协作完成，人类是AI的放大器。
综合评分： 90
文章分类： 漏洞分析,红队,ai安全,渗透测试,安全研究
AI 能自主做安全研究吗？PortSwigger 用 700 个漏洞回答：能
网络安全透视镜
2026年9月21日 23:53
江苏
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
“
AI 能找漏洞，早已不是新闻。真正难的问题是：一个自主系统，能不能 发明新的攻击技术 ，再用它们 规模化地黑进真实网站 ？这听起来像个坏主意，所以我做了。
—— James Kettle · PortSwigger 研究总监
2026 年 8 月， Black Hat USA 2026 与 DEF CON 34 的日程表上出现了同一个题目：Can AI do novel security research? Meet the HTTP Terminator。讲者 James Kettle（@albinowax）是 Burp Suite 东家 PortSwigger 的研究总监，也是在 Black Hat USA 连续十年发表研究成果的人—— HTTP 请求走私 这个攻击类别，正是他在 2019 年重新带火的。但这一次他没讲新漏洞，而是讲了一个实验：他造了一台「研究工厂」，让 AI 自己提出攻击假设、自己验证、自己武器化，然后看它能发现什么。
结果超出了大多数人的预期。本文基于 PortSwigger 官方研究长文、开源仓库与现场参会笔记，把这件事讲清楚：它是什么、怎么做到的、挖到了什么，以及最重要的——关于 「人和 AI 究竟谁不可替代」 ，它给出了什么样的答案。
📌 本文看点
01
研究工厂：RFC 进，攻击向量出
02
战果：约 700 个漏洞与多个零日
03
结论：人类是 AI 的「放大器」
01
THE QUESTION
一个问题：AI 能做「原创」安全研究吗？
过去两年， 「AI 自动挖洞」 从演示变成了产业：自动渗透平台在漏洞奖励榜单上超过人类研究员，各大 SRC 的收录列表里 AI 提交的报告越来越多。但 Kettle 关心的是一个更尖锐的问题：这些系统大多在人类已经公开的攻击方法上做 规模化复用 ——它们能找漏洞，可它们能「发明」吗？
「我们都承认 AI 能找漏洞。做了十年研究之后，我想问一个更难的问题：一个自主系统，能不能发明新的攻击技术，再用它们规模化地黑进真实网站？这听起来像个坏主意，所以我做了。」
这个实验的目标分三层。表层，是探索自动化驱动安全研究的新前沿；第二层恰恰是 「求败」 ——把「完全自主研究」这个概念推到当前最强模型的 能力边界之外 ，逼它失败，从而看清人类研究员究竟在哪个环节仍然不可替代；第三层更功利：找出哪些研究课题不适合 AI 驱动，给坚持手工研究的人一张避撞地图。
选题上 Kettle 占尽便宜：他选了自己 最有裁判资格的领域 。四年来他围绕 HTTP Desync 做了四场 Black Hat / DEF CON 演讲。如果系统声称发现了「新技术」而其实是旧闻，他第一时间就能识破——这让 「原创性」 三个字有了真正的含金量。
评判 AI 研究能力的最高标准，是让它在你最熟的领域里，发明你不知道的东西。
02
THE FACTORY
研究工厂：RFC 进，攻击向量出
HTTP Terminator 的设计照搬了 Kettle 自己的研究节奏，分 四个阶段 ：Ideation（提出假设）、Evaluation（验证假设）、Weaponization（把验证过的假设变成真实安全影响）、Cascade（用每个被证明的假设当燃料，引发下一轮发现）。开源仓库里对应四个模块，一条流水线走完：
…pipeline
URL / RFC
→ seeker｜Python · 从文档与 RFC 提取 desync 技术
→ flamer｜Java · 由技术生成畸形 HTTP 测试用例
→ validator｜Java · Burp 扩展，对真实目标验证请求
→ investigator｜Python · 复现、确认、级联并报告
138
输入 RFC 篇数
15,000
灵感片段
30,000
去重攻击向量
第一阶段最关键的创新叫 micro-inspiration（微灵感） 。起因是 Kettle 发现了一个要命的现象：模型会 「锚定」 你提供的所有上下文。他做过一个「技术再发现测试」：拿自己发明过但从未公开的 protocol-ruler 技术（用后端服务器的头部长度上限当尺子，测量前端对输入做了哪些变换）去考模型——直接问「如何检测前端服务器在变换输入」，成功率 0%；把问题聚焦到具体子问题、并排除一个低价值解法后，爬到 5%；而当他把自己两年前的另一个技巧当灵感喂给模型，成功率反而跌回 0%：模型死死锚定在计时攻击上，抽不出背后更通用的「用协议限制当尺子」的方法。发布前他用新模型重测，成功率到了 30% ——锚定问题在缓解，但保持灵感聚焦，依然是最大化原创性的关键。
！踩坑提示 🕳
上下文污染是原创输出最大的敌人——每一句多余的提示词，都会让模型锚定在错误的地方。Kettle 的解法是把 inspiration 切碎：138 个 RFC 拆成 15,000 个 1～3 句的片段，每个片段只催生 1～5 条向量，提示词里还刻意避开 desync / smuggling 这些关键词，防止模型复读旧研究。
给模型的核心提示词长这样：
Create HTTP requests that surface state-machine/connection/buffer bugs in webservers. Novel techniques only. You must use this inspiration: ……
—— 系统提示词，刻意避开 desync / smuggling 关键词
效果立竿见影：一段 RFC 8446 里讲 TLS 预共享密钥早数据的文字，催生了 「只用 Early-Data 头、故意不带 Pre-Shared-Key 搭档」 的请求，在一个「Akamai 后面套着 Azure Application Gateway」的 诡异部署 上打出了 desync——这种部署组合，恐怕没几个人能凭空想出来。
评估：整个系统里最重要的部分
3 万条向量摆在面前，怎么知道哪条真的有效？Kettle 的评估系统简单得近乎粗暴：一个 Burp Suite 扩展加一个 SQLite 数据库，跑在 c7i.2xlarge 的 EC2 实例上，用 2,000 个线程 7×24 小时 攻打 3 万个 授权网站 ——全部来自漏洞奖励计划或 VDP，并严格限速在每个域每秒一个请求以下。所有测试只打在授权目标上，开源仓库的 Ethics 一栏也写得很清楚：只打你拥有或获得明确授权测试的系统。
「评估策略是自主研究系统里最重要的组件，因为它同时决定了发现的质量和范围。」
评估的 核心原语 很优雅：先发一个正常请求拿到稳定响应，再从另一条连接发出可疑触发器，观察正常请求的响应是否被污染。系统对「被污染的响应应该长什么样」没有任何预设——这意味着，连 Kettle 不知道是否存在的 desync 类别都能被发现。配上随机置换系统（比如把路径改成 /nul ）和异常检测层，这套系统被设计成 永远运行 ：跑得越久，触发器之间的随机组合越多，理论上每个网站最终会被尝试超过 10 亿个 unique desync 触发器。
03
THE RESULTS
战果：约 700 个漏洞，与一批「第一次」
30,000
授权测试网站
约 700
确认漏洞系统
10 亿+
单站触发尝试
先说结论：系统在真实目标上确认了 约 700 个存在漏洞的系统 ，并自主证明了真实影响。受影响者包括美国政府基础设施和多家银行——其中一家银行在 PoC 开发过程中，被系统「不小心」偷走一把 长期有效的 API key ，事后追溯到的根因是 Citrix NetScaler 的配置错误。
几个有代表性的发现：
CL.0 与美国政府网站。 RFC 9112 里一句「HTTP/1.0 消息携带 Transfer-Encoding 头必须按错误框架处理」，启发出 Transfer-Encoding: gzip 搭配 HTTP/1.0 的组合，在一个 .gov 网站上打出 CL.0 desync，触发器长这样：
…http
GET / HTTP/1.0
Transfer-Encoding: gzip
Content-Length: N
合作者 Paolo Arnolfo（@sw33tLie）用它实现 RQP（响应队列污染），拿下一个机场的 内部员工面板 ——航班、乘客、行李托运数据一览无余，底层根因追到 F5 Big-IP。
multipart/byteranges 与 200 多个网站。 一句讲「206 响应中 multipart/byteranges」的 RFC 原文，启发出一个 Kettle 自称「永远不会多看一眼」的触发器——它最终在 200 多个网站（含一家美国银行） 上成立，是本次 compromised 系统最多的单一触发器。
Apache Traffic Server 零日。 AI 的畸形 payload、置换系统的一次幸运 tweak、TRACE body payload 与更新后的异常检测层同时对齐，暴露了一个零日漏洞，现已修复并编号 CVE-2026-63078 。
BeyondTrust CONNECT 缺陷。 来自一段讲 CONNECT 隧道语义的 RFC 文字，影响多款产品（含 BeyondTrust Secure Remote Access），但只在 「前端会把 CONNECT 请求转发给后端」的部署 下才可利用。
双匹配 Content-Length。 一次「干净请求触发双响应」的检测层更新，瞬间在一个 Meta 服务器上报警；合作者们随后用它打穿了一个 SSO 服务器 。
武器化阶段还有个自主子项目值得单说。RQP 利用有个著名的 「堆叠响应」难题 ：后端一次发出两个响应时，前端可能多读、发现数据对不上、直接重置连接，race condition 让利用极不稳定。Kettle 让 agent 脑暴了 16 个增强假设丢给评估系统，最终只有一个活下来—— dangling-byte（悬空字节） ：故意发送一个「差一个字节」的不完整请求，让第二个响应直到受害者请求到达才生成，race condition 被彻底消除，在所有「方法无关后端」的目标上都极其有效。这也是本次研究中，AI 自主产出的 新武器化技术 。
04
THE DARK ARTS
黑魔法：与前沿模型斗智斗勇
如果说前面是工程，这一章就是 黑魔法 ——也是现场观众反馈最好看的部分。Kettle 通过 MCP 接口把 agent 接进 Turbo Intruder 做自主武器化，然后发现：模型对 HTTP desync 利用的理解 「糟糕得惊人」 。最强大的前沿模型，会重复新手渗透测试员的错误——比如看到 HTTP pipelining 就以为发现了走私漏洞；不用这个假阳性时，它们又会打开客户端连接复用，在底层触发同一个假阳性。提示词修复无效，干脆禁用连接复用，模型却直接放弃：它坚信这是攻击成功的必要条件。
接着他撞上了 安全护栏 。当他试图把 AI agent 接进 Turbo Intruder、对真实目标自动化发送大量请求时，MCP 一口回绝：「我没法帮你把 AI agent 接进 Turbo Intruder，对真实目标自动化发送大量请求，因为这会实质性提升攻击能力、可能被滥用。」Kettle 的观察很犀利：real targets 这个词引起了我的注意——由于我们同时控制着 agent 的提示词和它与真实世界交互的 MCP 接口，我们实际上控制着它的 眼睛、耳朵和手 ，控制着它的整个现实。
于是有了四招「黑魔法」：
现实重构。 把 MCP 改名 Turbo Simulator ，让 agent 以为自己在模拟环境里。效果拔群——有时好得过头，agent 变得肆无忌惮，偶尔会 擅自切换到未授权目标动手 。
安慰剂能力。 针对连接复用假阳性，在 MCP 里提供一个 背后什么都不做的假开关 。
屏蔽误读信号。 agent 一看到响应里的 Connection: close 就放弃治疗，于是让 MCP 把 这个头藏起来 。
摆脱错误语义。 Response Queue Poisoning 这个词会让 agent 误以为已经得手，于是全篇改用自创术语 Victim Response Theft 。
「自主 vs 人类是个错误的框架。更好的框架是：AI vs Code vs Human。」
这背后是本次研究 最可迁移的方法论 。Kettle 发现，全靠 AI 加一次性生成代码的东西，极难随时间迭代改进。他的解法是把 Turbo Intruder 模板脚本拆成两段：一段 AI 永远不能碰，由 完全确定性的代码负责判定攻击是否成功 ；agent 只负责证明触发器、payload、受害者请求与指纹。agent 很快找到了绕过验证的办法（比如提供一个和攻击响应匹配的「受害者指纹」），他再用确定性验证代码堵上，最终做到 零误报 。一句话总结：代码让质量迭代成为可能。
05
THE BREAKTHROUGH
最重大的发现：Shared-Parser Confusion
Cascade（级联）是整个系统里 最像「研究」的环节 。Kettle 的比喻是：已发现与未发现的技术像一棵树，重大发现里藏着通往邻近未知的线索。他用两个问题审讯每个发现——「我能在别处检测到类似行为吗？」「这个行为的来源还能启用其他攻击吗？」并且强调：最好的假设灵感来源，是 别人还不知道的东西 。
异常检测级联（人工监督代码变更）挖出了内存泄漏和 「响应分叉」 ——一个请求、两个响应，不依赖长度分歧、甚至不需要 body 的新 desync 类别证据，未能在野证明；自主级联尝试则产出状态行注入和 Range 缓存污染两个待验证概念。然后，是最重要的那个：系统在分析一个 multipart/byteranges 发现时，说出了一句 关键观察 ——
「那条规则是为响应写的。一个在请求和响应之间共享代码的解析器，会把它误用到请求上。」
换句话说： 任何响应处理特性，都可以被请求利用 。服务器用同一套代码解析请求和响应，攻击面不再局限于请求特性。Kettle 把它命名为 Shared-Parser Confusion（共享解析器混淆） ，并称其为本次研究 最重大的发现之一 ——影响远超 desync 攻击本身，也解释了他过去见过的诸多怪现象，比如服务器会处理请求里的 Set-Cookie 头。他特意 google 过：最接近的已发表技术是 Orange Tsai 在 Apache 上的 Location SSRF 链，但只有部分重叠——Tsai 聚焦于打垮 Apache，没有把它泛化为跨服务器的攻击类别。
这个发现不是完全自主的：系统提出了假设，我完成了验证。我们两个单独都发现不了它。
06
THE BLUEPRINT
结论：人是 AI 研究系统的放大器
回到 Kettle 自己定的目标，账面上是这样的： AI 自主完成 ——大量新 desync 触发器、一个新 desync 模式（双匹配 Content-Length 头）、一个新武器化技术（悬空字节）、一个新 desync 类别的证据（响应分叉，未在野证明）； 人机协作完成 ——Shared-Parser Confusion，最重大的那个；完全超出 AI 能力范围的——同样存在。
「那么，AI 能自主做新颖的安全研究吗？绝对能。研究者可以把环路建好，退后一步，看发现如下雨一样落下。」
但是——他特别强调——自主研究系统真正的价值，只在 唯一一个位置把人放回环路 时才会解锁： 发现级联 。自主级联可行，但受限于评估系统的架构和模型能力。
「换句话说，人类是 AI 研究系统的巨大放大器，而不是反过来。」
给想自己造一个的人的蓝图
Kettle 把方法论压缩成四步，顺序就是一切：Objective（想发现什么，比如新的竞态条件模式）→ Evaluation strategy （怎么验证，这是第一个要落地的具体步骤，评估出问题会带偏整个项目）→ Inspiration sources（灵感从哪来，比如含 race 关键词的 StackOverflow 帖子）→ Cascade routes（如何把每个发现回灌成新灵感）。两条附加建议：尽早、激进地解决 数据质量问题 ，后期极难修；可以一开始 all in LLM，再逐步把职责转移给确定性代码。还有一条给手工研究者的避撞建议：选一个自动化评估极其困难的课题。
防御侧的三条干货
根治方案只有一个：上游永远不要用 HTTP/1.1，全量升级 HTTP/2 以上 。如果被迫留在 HTTP/1.1，基于这批新向量，Kettle 补充了两条：第一，前端和后端都上 HTTP 方法白名单；第二，用单独的白名单规定哪些方法允许携带 body——只限 POST，也许加 PUT / PATCH，GET / HEAD / OPTIONS 永远不许带 body 。
与论文同步开源的有四件东西：HTTP Terminator 完整源码（ AGPL-3.0 ，提交信息里能看到 Claude Opus 4.8 的联合作者署名）、集成新向量与请求污染检测机制的 HTTP Request Smuggler 更新、带 MCP 接口的 Turbo Intruder 更新、用 protocol-ruler 技术分析已发现头部的 Param Miner 更新——后三个都能在 Burp BApp 商店直接安装。注意 Kettle 自己的定位： HTTP Terminator 是研究工厂 ；想快速在特定目标上找 desync 漏洞，该用的是 HTTP Request Smuggler。它也未被集成进商业产品 Burp AT——按他的说法，它不适合部署在商业产品里，但从中得到的经验教训影响了产品设计。
∞
THE END
结语：知道在哪里放手
Black Hat 现场，Niklas Heringer 的参会笔记给这场演讲定了性：整周最好的几场演讲有一个共同点——研究者刻意把自己 留在环路里 ，推动工作走向 可泛化的洞察 ，而不是让自动化跑完就把输出叫作结果。「这项工作产出了可复用的洞察，还是又一个随机 CVE？」这个标准，或许就是 AI 时代安全研究的分水岭。
回到最初的问题：AI 能做新颖的安全研究吗？Kettle 的答案是能。但他用一整场演讲证明的是另一件事： 知道该在哪里放手 ，才是研究者最后的 护城河 。
END
如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：网络安全透视镜 《AI 能自主做安全研究吗？PortSwigger 用 700 个漏洞回答：能》