系统：运行中
EN FR ES ZH
⌕
← 返回所有攻击
AGENTS MEDIUM NEW

SSRF 补丁为何不牢：智能体框架中的 DNS 重绑定与被绕过的校验

2026 年 7 月的两则披露显示智能体框架的 SSRF 补丁如何失效：一个在校验后又重新解析主机名，另一个让部分请求路径根本不经过校验。

2026-07-22 // 7 min affects: mcp-atlassian, langflow, mcp-servers, ai-agents, rag

这是什么？

2026 年 7 月发布的两则披露指向同一个令人不安的事实：在智能体框架中交付一个 SSRF 补丁，并不等于从此免于 SSRF。SSRF（服务端请求伪造）缺陷让攻击者能让服务器去获取其指定的 URL——通常是为了抵达内部服务，或抵达 169.254.169.254 这样的云元数据端点，而后者可能返回 IAM 凭证。

2026-07-10，一则关于 MCP 服务器 mcp-atlassian 的 GitHub 公告，描述了如何用 DNS 重绑定（DNS rebinding）击败一个已经打过补丁的 SSRF 校验。另外，2026 年 7 月针对 Langflow（LLM 流水线的可视化构建器）的一则公告显示，某些遗留的抓取组件发出请求时，并未经过早前版本加入的 SSRF 保护。产品不同、机制不同，教训却一致：决定一次抓取是否被允许的那道边界，必须与真正打开套接字的那道边界完全一致。

工作原理

这两个案例以互补的方式失效。

在 mcp-atlassian 中，补丁加入了 validate_url_for_ssrf 检查。当请求在 X-Atlassian-*-Url 头部携带一个受攻击者影响的主机时，校验会解析该主机名一次，确认返回的每个地址都是公网（全局）IP，然后返回一个「通过/拒绝」的判定。问题出在它返回了什么：一个判定，而不是它刚刚批准的那个 IP。真正执行出站请求的代码随后是用原始主机名构建的，并在连接时重新解析。这道检查与使用之间的缝隙，正是经典的「检查时到使用时」（TOCTOU）竞态（CWE-367）。控制着自己域名权威 DNS 的攻击者，可以让第一次解析返回一个公网 IP（校验通过），让第二次解析返回一个内部地址（套接字连到那里）。结果就是打过补丁的版本上仍然出现 SSRF（CWE-918）。

# DNS 重绑定下的 TOCTOU —— 为什么「先校验再抓取」并不够

  t0  校验: resolve(host) -> 93.184.216.34  (公网)   -> 通过，判定被丢弃
  t1  抓取: resolve(host) -> 169.254.169.254 (元数据) -> 套接字连到这里

  校验与连接把同一个名字解析到了不同的 IP。

Langflow 的问题更简单，某种意义上也更常见：校验存在，但并非所有路径都经过它。早前版本引入的 SSRF 保护，没有覆盖某些遗留的抓取组件（一个 RSS 读取器和一个元搜索连接器），它们仍会直接向用户提供的 URL 发起请求。由于这些组件可以在智能体模式下运行，该 URL 甚至无需来自人类操作者：它可以通过智能体正在处理的内容中的间接提示注入送达。此处不复现任何可用的重绑定服务器或载荷；重点在于结构，而非配方。

为什么重要

这两个缺陷都存在于其全部职责就是让语言模型触及外部世界的软件里：一个与 Atlassian 对话的 MCP 服务器，一个抓取订阅源和搜索结果的流水线构建器。在这种场景下，提供 URL 的「用户」往往就是模型，而模型的输入可能被它刚刚读过的工单、网页或文档所塑造。此处的 SSRF 原语不是抽象的网络 bug：它是一条从不可信的智能体输入直达云元数据凭证和内部服务的直线，对应 OWASP LLM Top 10 中的工具与集成风险。

更深层的原因在于，这两者都是补丁不完整的故事。CVE 立了，补丁发了，仪表盘也变绿了——保护却依然不牢，或是因为校验与连接对「究竟联系了哪个地址」并不一致，或是因为第二条代码路径从不咨询校验器。这恰恰是自动化的「是否已修复？」检查会漏掉的那类回归。

防御

这一类问题的持久缓解，在于让「已校验的决定」一路生效到套接字：

  1. 把已校验的 IP 钉在连接上。 让 SSRF 检查返回它批准的那个具体地址，然后强制出站请求连接到那个 IP（自定义解析器、缓存的 getaddrinfo，或覆盖解析的适配器），同时保留原始的 Host 头。这样就关闭了 DNS 重绑定的窗口，因为不再有第二次可被投毒的解析。
  2. 所有出站只走一个收口。 让每一次出站抓取——包括遗留的、可选的、「图方便的」组件——都经由同一个已校验的 HTTP 客户端。像 Langflow 那样的 bug，正发生在某条旁路忘了校验器的存在时。
  3. 在连接时而非解析时封堵敏感目标。 在打开套接字时拒绝 link-local、回环和私有网段（以及元数据 IP），使一个迟到解析的名字无法绕过基于名字的允许列表。
  4. 把智能体提供的 URL 当作攻击者可控。 假设工具收到的任何 URL 都可能被模型摄入的内容所操纵；在工具边界处按「来自匿名网民」的标准进行校验。
  5. 对运行时施加最小权限。 优先使用 IMDSv2（或对应的云机制）并严格收紧实例角色，使得即便一次元数据抓取成功也收获甚微。

状态

项参考日期说明
mcp-atlassian SSRF（头部）CVE-2026-27826 / GHSA-7r34-79r5-rcc92026最初的 X-Atlassian-*-Url SSRF；补丁加入了 validate_url_for_ssrf
重绑定绕过GHSA-489g-7rxv-6c8q2026-07-10修复不完整；TOCTOU（CWE-367）+ SSRF（CWE-918）；判定未钉 IP；已在 0.22.0 修复
Langflow SSRFCVE-2026-105462026-07遗留抓取组件绕过 1.9.3 加入的保护；可经智能体工具模式触达
类别OWASP LLM Top 102025不安全的工具/集成设计、过度自主

以上细节均来自厂商公告与公开 CVE 记录；两个问题均已披露。教训超出这两个产品：任何会抓取 URL 的智能体框架都应假设——校验一个主机名之后再重新解析它，或是留下第二条无人把守的抓取路径——都会重新打开补丁本应关上的那个洞。

Sources