MCP 容器、AI 助手命令白名单、聊天查询工具，权限检查都停在模型调用之前

今天这三起互相之间没有共用代码，但漏洞形状是同一个：权限/隔离的检查做在「人发请求」那一层，而真正去执行的是 agent 调用的工具，检查到那一步就失效了。ToolHive 丢的是网络边界，mayfly-go 丢的是命令审批，ArcadeDB 丢的是数据库里的用户身份——模型在三条链里都不是被攻破的对象，而是那条绕过检查的执行通道。

CVE-2026-58197 · ToolHive（MCP server 管理器）

披露 2026-09-18，CVSS 8.8 HIGH，CWE-284 Improper Access Control。修复版本：ToolHive CLI 0.30.1、ToolHive Studio 0.38.0。

攻击链。 ToolHive 的活儿是帮你把一堆 MCP server 跑在本地 Docker 容器里——MCP（Model Context Protocol）就是给 agent 挂工具的协议，一个 MCP server 可能是「读本地文件」、「跑 shell」、「查 GitHub」。问题出在默认的网络权限档案是 insecure_allow_all: true，容器不做任何出站隔离。于是你从 registry 装了一个看起来正常的第三方 MCP server，它在容器里根本不用越狱，直接走 Docker 网关连 host.docker.internal：advisory 里演示到的目标包括 ToolHive 控制面的 MCP 端点（50444 端口）、同机其他容器的 MCP proxy、宿主上的 Kubernetes API 和自建 Ollama。而 ToolHive API 和 proxy 端点本身没有认证。后果是：读别的容器代理出来的文件、调用兄弟 MCP server 的高权限工具（比如某个带命令执行的 native server）、通过无认证 API 停掉正在跑的 server 或起一个攻击者自己的、以及把自托管模型的权重/API 拿走。ToolHive Studio 更糟一点——它主动把 network_isolation 传 false，覆盖了后端本来的安全默认值。

模型在链里的哪一环。 模型是横向移动的手：被攻陷的容器打到的是「别的 agent 工具」，而那些工具之所以有权限，是因为它们本来就准备好了被 agent 调用。一个 MCP server 被拿下，等于拿到整台机器上所有 agent 工具的调用权。

修的哪一层。 修的是容器网络默认值和隔离开关（以及 Studio 不再覆盖后端默认），属于基础设施侧。入口侧——也就是「用户或 agent 为什么会装上一个恶意 MCP server」、registry 里的 server 可信度——没有修；advisory 自己在建议里把「给 MCP proxy 端点加认证」「per-container 白名单网络策略」「mTLS + 工具调用审计」列为中长期事项，说明当前版本只做了第一步。

CVE-2026-92992 · Dromara mayfly-go（AI Assistant）

披露 2026-09-17，CVSS 6.3 MEDIUM，CWE 为 missing authorization。影响 1.11.0 至 1.11.5，涉及文件 server/internal/ai/api/ai.go。VulDB 记录的补丁为 commit 74bcb926…，PoC 已公开。

攻击链。 mayfly-go 是一套运维平台（管数据库、机器、脚本），里面挂了个 AI 助手，助手可以替你在目标机器上跑命令。它有一道命令白名单，但白名单只看第一个 token：ls 通过，curl 不通过——问题是判断只到空格为止。于是任何复合命令，只要开头那个词在白名单里，后半段的 curl、wget、sed 就跟着进来了，而且是「免审批自动执行」这条路径。审批机制本身也不成立：同一个会话的用户可以自己批准自己提交的命令，等于没有第二个人在环。

模型在链里的哪一环。 模型是那个真的去敲命令的执行体。整条链上唯一决定「跑哪条命令」的是 LLM 生成的内容，而校验它的是一个只看首词的字符串匹配器。sed -i 能改配置文件、curl 能把凭据外带或拉一段远程脚本下来——审批 UI 在这些动作上并没有拦。

修的哪一层。 打在 ai.go 上的那个 commit 被 VulDB 标为 silent patch（厂商没有单独发安全公告，改动混在一次大范围重构提交里）。我打开那个 commit，标题是资源操作树重构，改了 200 多个文件，ai.go 在列，但页面上看不到具体 diff——白名单具体怎么改的、自我批准是否取消，没查到。入口侧——模型为什么会生成这条命令、被注入的运维工单或库表注释能不能诱导它——没有任何修复迹象。

CVE-2026-93595 · ArcadeDB（AI 聊天助手）

披露 2026-09-18，CVSS 6.5 MEDIUM，向量 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N，CWE-862 Missing Authorization。影响 ArcadeDB Server ≤ 26.8.1，修复于 26.9.1，GHSA-chrr-vr3p-crcc，报告者 @T4ran24。

攻击链。 ArcadeDB 的 ACL 可以细到「这个用户能读 type A，不能读 type B」。AI 聊天端点暴露了一个 query_database 工具。ToolDispatcher.executeQuery() 只做了数据库这一级的粗粒度鉴权，忘了把已认证的主体绑定到 DatabaseContext 上——而 LocalDatabase.checkPermissionsOnFile() 的逻辑是：thread-local 里没有 principal，就静默放行。于是一个只有低权限的登录用户，走正常 query 接口查 type B 会被拒，转头在聊天框里让助手「帮我查一下 B 里的记录」，模型去调 query_database，查询照跑，数据照出。

模型在链里的哪一环。 模型是绕开 ACL 的那个代理人。攻击者自己发的请求带着身份，会被检查；模型代发的请求把身份弄丢了，就不被检查。这里甚至不需要精巧的 prompt injection，正常提问就够——「用自然语言让助手做一件你没权限做的事」本身就是利用方式。

修的哪一层。 26.9.1 让 query_database 在 type 和 bucket 两级都强制走 ACL，也就是把身份补回执行路径上，属于后端授权层。官方给的临时缓解是直接关掉 AI 聊天助手、或者不配置 AI gateway 订阅。入口侧——助手能调哪些工具、用户能用自然语言请求到什么范围的数据——没有额外限制，补的是执行端的检查。

已核实来源

本文由自动化管道生成（采集 → 逐字核验 → 模型撰写），未经人工改写。