前言

在 AI 大模型与 Agent 蓬勃发展的今天，像 FastGPT 这样允许用户自定义工作流（Workflow）的平台，不可避免地引入了大量出站网络请求。为了防御 SSRF（服务端请求伪造），开发者通常会采用黑名单机制。

然而，在 FastGPT v4.14.11 及更早版本中，存在一个 CVSS 评分高达 7.7 的 SSRF 漏洞（CVE-2026-42345）。令人深思的是：代码中明明存在 isInternalAddress 这样的防御函数，甚至硬编码了各大云厂商的元数据地址，为何防线依然被轻易击穿？

本文将从代码审计切入，结合动态复现，揭示这场由“字符串信任危机”与“默认配置失效”共同导致的防御崩塌。

一、 代码审计：寻找防线

系统在处理用户输入的 HTTP 请求时，会调用 packages/service/common/system/utils.ts 中的 isInternalAddress 函数进行安全检查。

1. 疑似存在的兜底防线

图注：代码第 12 行存在 isDevEnv 短路逻辑。若系统处于开发环境，该函数直接返回 false，跳过所有后续校验。

2. 脆弱的黑名单与“认知错位”

进入后续逻辑，开发者维护了一个庞大的 metadataEndpoints 数组，试图阻止对 AWS、阿里云、腾讯云等元数据地址（如 169.254.169.254 ）的访问。

图注：第 145 行的 startsWith 判断是整个漏洞的根源。开发者使用了错误的字符串前缀匹配，将字符串字面量与真实的网络地址划等号。

审计切入点：
开发者做了一个致命的安全假设——攻击者会以标准、规范的字符串形态（ http://169.254.169.254/ ）提交请求。

然而，URL 标准与底层的网络解析库（如 Node.js 的 new URL()、axios 甚至操作系统的 Socket API）远比字符串匹配要宽容得多。同一个 IP 地址，存在无数种等价的表达方式：

由于这些变体在字符串层面并不以 http://169.254... 开头，startsWith 的校验完美失效，请求将被直接放行。此外，由于系统全局环境变量 CHECK_INTERNAL_IP 默认值为 false，底层的 IP 兜底校验根本不会执行。

二、 环境搭建与漏洞复现

环境说明：本次复现基于 FastGPT v4.14.11 版本，使用 Docker 部署基础依赖（MongoDB、Redis、Sandbox 等）。

图注：FastGPT 完整微服务依赖环境已成功就绪。（注：沙盒服务因本地网络受限于健康检查，但不影响核心 HTTP 节点的测试）。

图注：FastGPT 服务正常启动并成功登录。

为了直观展示 SSRF 的危害，我们在本地（宿主机的 8080 端口）编写了一个极简的 Node.js 服务，用于模拟云服务器元数据接口。

图注：本地伪造的云元数据接口 http://127.0.0.1:8080 成功启动，用于验证 PoC 的读取结果。

第一步：验证防御机制（对照组）

我们在 FastGPT 工作流中创建一个 HTTP 请求节点，填入标准的内网回环地址。

结果：请求被成功拦截，系统返回 "message": "Request to private network not allowed"。

图注：第一层防御生效。常规的明文内网探测确实被应用层防护阻断了。

第二步：十六进制绕过（致命一击）

我们构造了针对云元数据地址 169.254.169.254 的十六进制变体，尝试发起请求。

结果：请求成功穿透了 isInternalAddress 的防线。底层的 Node.js 网络库成功接收并解析了该地址，试图发起 TCP 连接。

图注：关键证据！报错 connect ENETUNREACH 169.254.169.254:8080 表明请求不仅没被安全拦截，反而下沉到了网络层，直指真实的云元数据 IP。如果在真实云环境中，此处将直接返回泄露的 IAM 临时凭证。

三、 从漏洞复现到 SOC 检测的深度反思

作为安全从业者，我们不能仅仅停留在“黑名单被绕过”的表象上。这个 CVE 折射出的“检测同构性错误”，对 SOC（安全运营中心）和 AI 基础设施的安全防护极具警示意义。

1. 纵深防御的全面失效

在这个案例中，FastGPT 的防线是割裂的：

  • 第一层：应用层的 startsWith 字符串匹配（被十六进制绕过）。

  • 第二层：网络层的 CHECK_INTERNAL_IP 兜底校验（因默认值为 false 而关闭）。
    这意味着，默认配置下的 FastGPT，在 SSRF 防护上几乎是“裸奔”的。

2. WAF 与 SOC 检测的“同构性危机”

如果你是一名蓝军/SOC 分析师，你会如何写这条告警规则？很多安全人员会写：HTTP_URL CONTAINS " 169.254.169.254 "。
这与 FastGPT 开发者的错误如出一辙！只看字符串字面量，必定会被进制转换、URL 编码、DNS 重绑定（DNS Rebinding）等技术轻易绕过。 有效的安全检测，必须依赖于设备侧或者流量侧的“连接真实 IP”，而不是“URL 解析出的字符串”。

3. Agent 场景下的 SSRF 威胁放大

在 AI Agent（如 MCP 模型上下文协议）中，大模型可以根据用户的 Prompt 自主调用工具。这意味着，攻击者可以通过精心构造的提示词注入（Prompt Injection），诱导 AI 自动去触发这个十六进制 SSRF Payload，实现全自动化的内网渗透，无需受害者手动点击。

四、 修复建议

修复的核心不在于“无限加长黑名单”，而在于改变校验的时机：

1. 关闭危险配置：

在生产环境中强制设置环境变量 CHECK_INTERNAL_IP=true。

2. 解析而非匹配：

使用标准库 new URL(url) 提取出 hostname。

3. 底层 IP 判定：

对 hostname 进行 DNS 解析（dns.lookup），获取其真实 IP 地址，并判断该 IP 是否属于私有网段（RFC 1918）或链路本地地址（ 169.254.0.0/16 ）。

4. 防范 DNS 重绑定：

在发起请求时，使用底层网络库的钩子（如 Axios 的 lookup 方法），确保实际建立连接的 IP 就是校验时通过的 IP。

免责声明：本文涉及的技术仅供安全研究和交流，请勿用于非法用途。复现环境为作者本地搭建，模拟数据不涉及真实云环境凭证。