本文使用的 Docker 镜像
发布日期: 2026 年 9 月 19 日
风险等级: 高危(High)
漏洞编号: CVE-2026-58197
CVSS: 约 8.8(High;CVSS v3.1)
相关公告: GHSA-qg2g-g9w3-m5h8 · ToolHive CLI v0.30.1
一、漏洞概述
ToolHive(Stacklok)用于简化 Model Context Protocol(MCP) 服务的部署与管理,常见形态为本地 CLI(thv) 与 Studio 桌面产品:由 ToolHive 拉起 Docker 容器运行各类 MCP 服务器,再经本机代理对接 AI 客户端。
经官方确认,在 ToolHive CLI 0.30.1 之前、ToolHive Studio 0.38.0 之前:
- 本地 MCP 容器默认使用
insecure_allow_all: true一类网络权限配置,未做网络隔离; - 容器内可解析并访问
host.docker.internal(以及 Docker gateway,如172.17.0.1),从而触达宿主机本机监听的服务; - ToolHive API / MCP 代理端点当时无认证,任意能连上端口的客户端即可完整交互;
- Studio 还会下发
network_isolation: false,覆盖后端更安全的隔离默认值。
因此,恶意或被攻陷的 MCP 容器无需逃逸,即可:探测宿主机本机端口、调用其他 MCP 代理工具、触达 ToolHive 控制面,甚至访问本机 Kubernetes API、Ollama 等服务——构成 横向移动与跨 MCP 越权。
重要说明: 威胁模型是「已在 ToolHive 下运行的(恶意 / 被控)MCP 容器 → 宿主机 localhost 面」,不是「互联网未认证扫端口即可打穿」。但一旦引入不受信 MCP 镜像或容器内负载被攻陷,隔离假设即被打破。
二、漏洞状态
统计截止: 2026 年 9 月 19 日(UTC+8)
| 项目 | 状态 |
|---|---|
| 漏洞细节 | 已公开(GitHub Security Advisory / CVE) |
| 漏洞类型 | 默认配置不安全 / 缺失网络边界 + 无认证控制面 |
| 官方补丁 | 已发布(CLI ≥ 0.30.1;Studio ≥ 0.38.0) |
| 修复行为变化 | 默认开启网络隔离;访问 Docker gateway / 宿主机需显式允许 |
| 在野大规模利用 | 暂未发现公开大规模在野攻击报道 |
三、影响范围
1. 版本与产品形态
| 产品 | 受影响范围 | 修复线 |
|---|---|---|
ToolHive CLI(thv) | < 0.30.1 | ≥ 0.30.1 |
| ToolHive Studio | < 0.38.0 | ≥ 0.38.0 |
产品本体说明: 漏洞落在 CLI / Studio 编排与默认网络策略,而非某一个固定的「ToolHive 基础应用镜像」换 tag 即可一键修完。修复方式是升级本机 ToolHive,并 重启 既有本地 MCP 工作负载使新默认生效。
2. 典型受影响场景
- 本机 Docker Desktop / Docker Engine 上用
thv run或 Studio 拉起容器化 MCP - 同机还跑着 仅监听 localhost 的敏感服务(K8s API、Ollama、原生 MCP、其他代理)
- 从社区 catalog / 第三方来源引入 不受信 MCP 镜像,或 MCP 进程本身可被供应链攻陷
- 升级前 Studio 强制关闭网络隔离,覆盖 CLI/后端更安全的默认
风险边界提示:
- 官方说明 Kubernetes Operator 路径不受本默认值翻转影响(与本地 Docker 拉起场景不同)。
- 已在跑的旧容器通常需 停止后按新版本重启 才会吃到隔离默认;仅升级二进制不重启,风险窗口仍在。
四、修复建议
1. 升级 ToolHive CLI / Studio(推荐)
| 产品 | 最低建议安全版本 | 参考 |
|---|---|---|
| ToolHive CLI | ≥ 0.30.1 | Release v0.30.1 |
| ToolHive Studio | ≥ 0.38.0 | 见官方 Studio Release / advisory 交叉引用 |
升级后的关键行为(CLI v0.30.1+):
bash# 默认:网络隔离开启(推荐) thv run my-server # 需要访问宿主机 Docker gateway / host.docker.internal 时显式允许 thv run --allow-docker-gateway my-server # 完整退回旧行为(不推荐,仅兼容场景) thv run --isolate-network=false my-server
REST API 侧:network_isolation 改为可选指针;省略该字段现表示隔离开启。必须关闭隔离时需显式传 false。
2. 版本自查
bashthv version # 或 thv --version
确认 CLI ≥ 0.30.1;Studio 在关于页 / 安装包版本中确认 ≥ 0.38.0。然后 重建 / 重启 本地 MCP 工作负载。
3. 与 MCP 业务镜像的关系(示例)
官方复现曾使用容器化 MCP(如 mcp/filesystem)演示从容器侧访问 host.docker.internal。这类镜像是 被 ToolHive 拉起的工作负载,升级 ToolHive 才能改变其默认网络边界;仅换 MCP 镜像 tag 不能 单独修复本 CVE。
Docker Hub: mcp/filesystem
轩辕镜像: mcp/filesystem
拉取示例(业务 MCP 镜像;不能替代 ToolHive 本体升级):
bashdocker pull docker.xuanyuan.run/mcp/filesystem:<标签>
具体 tag 以 Hub / 轩辕站内列表为准。生产环境固定明确版本。
4. ToolHive 本体
本漏洞修复依赖官方 CLI / Studio 安装包升级(见上文版本表与 Release),与换某个基础应用镜像 tag 无关。
五、临时缓解措施
在无法立即完成升级前,建议:
-
停止不受信 MCP
勿用旧版 ToolHive 拉起来路不明的 MCP 镜像;对已运行工作负载做清单审计。 -
减少宿主机 localhost 暴露
本机 K8s API、Ollama、高权限原生 MCP 等尽量绑定更严的监听策略,或与 MCP 开发机隔离(不能替代升级)。 -
升级后避免随意关隔离
不要习惯性加--isolate-network=false;确需访问宿主机时优先用--allow-docker-gateway,并记录审批原因。 -
勿使用
--network host跑 ToolHive 管理的 MCP
host 网络会进一步抹平容器边界,与本漏洞威胁模型叠加后风险更大。
六、与轩辕镜像用户的相关说明
轩辕镜像提供的是 镜像加速与拉取服务,不替代 你对 ToolHive CLI / Studio 的版本升级与网络隔离策略。
- 通过轩辕拉取
mcp/filesystem等 MCP 业务镜像,不会自动修复 CVE-2026-58197;必须升级 ToolHive 本体。 - 配置与排错可参考:轩辕镜像使用手册、镜像拉取 FAQ。
七、参考链接
- GitHub Security Advisory:GHSA-qg2g-g9w3-m5h8
- ToolHive CLI 修复版:v0.30.1
- CVE 条目可检索:CVE-2026-58197
- Docker Hub(示例 MCP 镜像):mcp/filesystem
- 轩辕站内镜像页:mcp/filesystem
- 项目主页:https://github.com/stacklok/toolhive
轩辕镜像安全团队
2026 年 9 月 19 日
评论交流
免责声明
本博客文章所提供的内容、技术方案、配置示例及部署指南等信息,仅供学习交流和技术参考使用。文章内容基于发布时的技术环境和版本信息编写,可能因时间推移、技术更新或环境差异而存在不适用的情况。
用户在参考本博客内容进行部署操作前,应当充分了解相关技术风险,并建议在测试环境中进行充分验证和测试,确认无误后再考虑在生产环境中使用。生产环境部署前,请务必进行数据备份,并制定相应的回滚方案。
用户因使用本博客内容进行部署操作而产生的任何损失、数据丢失、系统故障、安全风险或其他问题,均由用户自行承担全部责任。轩辕镜像官方不对因使用本博客内容而产生的任何直接或间接损失承担责任。
本免责声明的最终解释权归轩辕镜像官方所有。
