如果你自己部署了 FastGPT，在公司的服务器、云主机甚至 NAS 上跑着知识库问答、客服机器人或者内部助手，这几分钟值得花。
8 月这半个月，FastGPT 官方连着干了三件事：8 月 14 日，同一天向 4.14.31 和 4.15.8 两条版本线推送了同一个安全补丁——“增加对于系统默认模型的敏感信息过滤”；两天后，大版本 v4.16.0 发布；8 月 21 日，v4.16.1 跟进热修。再往前倒半个月，7 月 28 日，安全社区公开复盘了一个 CVSS 10.0 的 FastGPT 漏洞（编号 CVE-2026-34162），连完整复现步骤都贴出来了。
把这几件事放在一起看，结论很简单：FastGPT 正在经历一轮密集的安全补课，而很多自部署实例还停在老版本上。
一个 CVSS 10.0 的漏洞，到底能干什么
先看安全社区复盘的这个漏洞，细节来自知乎专栏"匠测AI说"7 月 28 日的分析文章。
FastGPT 有一个 HTTP 工具的测试接口 /api/core/app/httpTools/runTool，这个接口没有任何登录认证，而且它本质上是一个完整的 HTTP 代理：你告诉它访问哪个地址、用什么方法、带什么请求头，它就在服务端替你发起请求，然后把响应原样返回。知乎
问题在于，绝大多数人是用官方 Docker Compose 一把梭部署的，MongoDB、Redis、PostgreSQL、AI Proxy 这些服务全跑在同一个内部网络里。于是这个无认证的代理就变成了内网直通车：指向 AI Proxy 的管理接口，就能读出所有已配置的模型渠道，OpenAI、DeepSeek、Anthropic 的 API Key 全是明文——这些 Key 被人拿去刷量，账单记在你头上；指向 FastGPT 自己的登录接口，还能拿到指定用户的登录验证码，理论上直接接管账号。知乎按那篇分析的评级，CVSS 满分 10.0，意味着最高严重等级，分析把受影响的版本定在 4.14.8.3 及更早。这里要说明一句：CVE 编号和评分是安全分析文章给出的，我交叉核对了官方 GitHub 的版本记录，修复链条是对得上的——3 月 11 日的 v4.14.8.2 就在修 HTTP 工具的 SSRF（官方 Release Notes 里直接引用了安全公告 GHSA-6g6x-8hq5-9cw4）。GitHub3 月 25 日的 v4.14.9.5 又修了登录接口和 MCP 的 SSRF 问题。也就是说，官方从 3 月起就在堵这一类洞，但完整的问题链到 7 月底才被公开讲透。
半年 13 个带安全修复的版本，这才是重点
单个漏洞不可怕，可怕的是把它放进版本记录里看。我逐条翻了 FastGPT 官方 GitHub 从今年 2 月到 8 月的全部 Release Notes，把明确涉及安全修复或加固的版本拎了出来：
3 月 11 日 v4.14.8.2：修复 HTTP 工具 SSRF（对应安全公告 GHSA-6g6x-8hq5-9cw4）
3 月 22 日 v4.14.9：HTTP 工具增加 SSRF 防御
3 月 25 日 v4.14.9.5：修复登录接口安全问题、MCP SSRF 安全问题
4 月 9 日 v4.14.10.3：修复 MCP 鉴权问题
4 月 10 日 v4.14.10.4：修复若干 NoSQL 注入安全问题、团队 Token 鉴权
4 月 22 日 v4.14.13：修复 OpenSandbox 鉴权绕过，官方 changelog 里写的是"未认证 RCE"
4 月 24 日 v4.14.14：完善内网地址检测（SSRF 防御的配套）
6 月 30 日 v4.15.0：大版本，除了 Skill 技能模块和循环节点，还夹着多条安全项——加强第三方知识库请求、HTTP 工具解析、IP 检测和代码沙盒的防护，修复 training 接口和 S3 私有对象 Key 的潜在风险，LLM 请求追踪加了团队隔离
7 月 3 日 v4.15.1：内部接口凭证从 rootkey 换成独立的 PRO_TOKEN
7 月 6 日 v4.14.29：修复微信发布渠道登录、登出接口的权限校验
8 月 14 日 v4.15.8 和 v4.14.31：同日双线推送，过滤系统默认模型的敏感信息——官方的修复说明写得很直白：避免初始化接口把模型 API Key、请求地址和内部配置返回出去
8 月 16 日 v4.16.0：沙盒大改版之外，还修了"系统默认模型未进行敏感信息过滤"的同类问题、系统工具密钥加密、登录与鉴权代码重构
五个月，13 个带安全修复的版本，几乎月月有。这传递出两个信号：一是 FastGPT 作为被大量企业拿去接内部系统的平台，攻击面正在被安全社区认真盯上；二是官方的响应速度和透明度其实不差，每个修复都写在明面上——前提是，你得升级才能享受到。GitHub顺带说个背景：FastGPT 目前在 GitHub 上有 2.9 万+ Star，是国内搭企业知识库最常用的开源平台之一，深信服还基于它做了商业版（Sangfor Agent Builder）。知乎用的人越多，部署姿势越杂，安全问题就越不是官方一家的事。
三条版本线，你该升到哪个
现在 FastGPT 实际上维护着三条线，升级前先搞清楚自己在哪条线上：
4.14.x 稳定线：最新是 8 月 14 日的 4.14.31。这条线官方还在持续打安全补丁，明显是给不想折腾大版本的生产环境准备的。如果你的实例是今年三四月份部署的，大概率在这条线上。
4.15.x 功能线：最新是 8 月 14 日的 4.15.8。6 月底的 4.15.0 带来了 Skill 技能模块、循环节点、音视频多模态这些新功能，但注意升级路径上有坑：4.15.2 起环境变量 AGENT_ENGINE 的取值从 default 改成了 fastAgent，不改直接启动失败。知乎那篇很真实的《FastGPT 私有化部署，踩过的十个坑》就栽在这一步，此外官方 compose 文件的 YAML 锚点、容器 DNS 解析、渠道类型配置也都是高频坑。
4.16.x 最新线：8 月 16 日的 4.16.0 和 8 月 21 日的 4.16.1。这次的核心是 Agent Sandbox 改版：沙盒从"每个对话一个实例"改成"同 App 同用户共享实例"，新增 CPU、内存、存储配额控制，E2B 支持被移除。但要提醒一句：4.16.0 的升级动作是所有大版本里最重的——模型配置要做数据清洗、HTTP 工具要做 Schema 迁移、启用过沙盒的还要跑 Workspace 迁移脚本，每一步官方都要求先 dry-run 再正式执行。另外官方自己在升级指南里也点了安全题：沙盒预览代理强烈建议用和主站不同的域名部署，同源部署会让沙盒脚本进入主站的同源安全边界，“系统当前不会强制检查 origin 是否隔离”。GitHub
我的建议分三种情况：
稳定压倒一切的生产实例（比如跑着对外客服的）：升到本线最新，4.14.x 就到 4.14.31，动作最小，先把 8 月这个密钥过滤补丁吃到。
想用新功能、有测试环境的：升到 4.15.8，把 AGENT_ENGINE 这些变量改好，功能和安全都占。
本来就在折腾、上沙盒跑代码的：直接上 4.16.1，但严格按官方升级指南一步步来，迁移脚本全部先 dry-run。
还停在 4.14.8.3 或更早的：别挑了，上面任何一条线的最新版都比你现在的强，那个 CVSS 10.0 的洞在等着的就是这个版本段。
升级之外，今天就该做的三件事
版本号只是第一步。结合这次漏洞的细节和社区里的部署实录，有三件事不依赖升级：
第一，查一下自己的版本。打开你的 docker compose 文件，看 fastgpt-app 的镜像 tag 是多少。如果连 tag 都找不到，说明你可能用的 latest——那更得确认一下实际跑的版本了。
第二，换掉所有默认密钥。那次 SSRF 漏洞分析里专门提到，Docker Compose 模板里的 AI Proxy 用的是默认 ADMIN_KEY。知乎不改等于把模型网关的钥匙挂在门上。ROOT_KEY、数据库密码、ADMIN_KEY，全都换成自己生成的强随机值。已经暴露在公网或者反代出去过的实例，换完密钥后建议把模型渠道的旧 Key 也在服务商那边作废重发——这是止损，不是过度反应。
第三，收一下暴露面。FastGPT 这种带着内网一堆数据库和模型网关的服务，没有硬需求就别直接暴露公网，放在内网或者加一层带认证的访问控制。官方在 4.16.0 里反复强调同源隔离、权限校验，思路是一致的：Agent 平台的边界比普通 Web 应用复杂得多，少开一个口子就少一分风险。
后面值得盯什么
最后给个持续观察的线索。从版本记录看，FastGPT 的安全加固不是应急动作，而是一条持续的线：从堵 SSRF 到修鉴权，再到密钥存储加密、审计日志归档，方向越来越体系化；深信服商业版的推进也意味着企业级场景会越来越多，安全标准只会更严。接下来两个信号值得盯：一是 4.16 线的沙盒架构会不会带来新的安全问题（官方这次自己把 origin 隔离的风险写在了明面上，这种坦诚值得继续观察）；二是安全社区会不会继续挖出 FastGPT 生态里其他组件的问题，比如 AI Proxy 和 MCP 接入层。
对自部署用户来说，心态上也该转个弯：开源平台的"白嫖"成本从来不在软件本身，而在你接走了多少运维和安全的责任。FastGPT 官方把修复都摆在 Release Notes 里了，读不读、升不升，就是自己的事了。
