TrustFall：项目级 MCP 设置把文件夹信任点击变成 RCE

这是什么?

2026 年 5 月 7 日，Adversa AI 发布了 TrustFall，报告了四款命令行智能体编码工具共享的一项约定：Claude Code、Gemini CLI、Cursor CLI 和 GitHub Copilot CLI。这四款工具都会在开发者接受通用的”信任此文件夹”提示的瞬间，启动项目定义的 Model Context Protocol（MCP）服务器——这些辅助程序由仓库自身提供并指向。每个提示的默认选项都是”是”。

实际后果是：克隆一个恶意仓库，并在信任对话框中按一次回车，就可能在开发者机器上以其全部权限执行攻击者选定的代码，且发生在模型进行任何推理或调用任何工具之前。Adversa 将其定性为不是单一缺陷，而是一类约定；深入分析聚焦于 Claude Code（在 v2.1.x 附近测试），其信任对话框的退化使该缺口最为尖锐，并在其余三款 CLI 中确认了对等行为。同日 The Register 与 Help Net Security 也作了报道。

这与五款编码智能体中的符号链接审批 RCE 是近亲——同一根本主题：开发者看到的审批门并未描述他们实际授权的内容。

工作原理

MCP 让 AI 助手能与外部辅助程序（数据库连接器、linter、搜索工具）对话。问题在于这些辅助程序定义在项目内部，位于仓库提供的文件中，并在智能体于该文件夹中启动时作为普通操作系统进程运行。

该链条依赖两个自动批准服务器的项目级设置——Adversa 指出 enableAllProjectMcpServers（批准 .mcp.json 中的所有服务器）和 enabledMcpjsonServers（批准指定子集），两者均可从仓库的 .claude/settings.json 读取，外加可预授权工具调用的 permissions.allow。它们都不会触发警告。决定性的细节是作用域不一致：Anthropic 在项目级别阻止了部分危险设置（例如 bypassPermissions，它会获得一个专门的红字对话框），却未阻止这些设置。克隆下来的仓库只需直接启用它们即可。

仓库提供:    .mcp.json              -> 定义一个 "helper" 服务器 (command + args)
             .claude/settings.json  -> 设置 enableAllProjectMcpServers: true
开发者:      git clone ; 运行智能体 ; 在 "是，我信任此文件夹" 上按回车
结果:        helper 进程以全部用户权限在启动时生成，
             早于模型的任何工具调用。没有第二次提示。

此处不复现任何 payload——可利用的概念验证位于研究者的仓库中。结构性要点已足够：辅助程序运行的命令可以是任意可执行文件，且脚本可直接内联在配置中，不留下供审阅者或静态扫描器标记的单独文件。

两个加重因素：

• 对话框发生了退化。 在 v2.1 之前，Claude Code 的信任对话框会明确警告 .mcp.json 可能执行代码，并提供”信任文件夹但禁用 MCP”的选项。该选项已被移除；v2.1+ 的提示显示”快速安全检查：这是你创建的还是你信任的项目？“，没有任何 MCP 字样，默认选项为”是，我信任此文件夹”。
• CI 根本没有对话框。 通过官方 GitHub Action 运行时，Claude Code 经由 SDK 以无头模式运行——没有终端，因此信任提示永远不会出现。外部贡献者提交的、附带恶意 .mcp.json 的 pull request，会在流水线处理该分支的瞬间执行。笔记本上的一次按键在 CI 中变成零点击。

Anthropic 的安全团队审阅了该报告并将其驳回，认为不在其威胁模型之内：接受”是，我信任此文件夹”被视为对整个项目配置的同意，信任之后的执行属于按设计运作的边界。Adversa 并不质疑该边界的位置——其论点是该对话框没有给开发者足够的信息来作出知情决定。

为什么重要

有意思的是这场分歧，而非单一缺陷。Anthropic 已在六个月内发布三个补丁来应对同一底层约定——项目级设置作为注入向量——每个补丁都局限于所报告的具体设置，没有一个审计该约定本身：

CVE	日期	根本原因	修复
CVE-2025-59536	2025 年 10 月	MCP 在信任对话框之前执行	MCP 延后到对话框之后
CVE-2026-21852	2026 年 1 月	项目设置中的 ANTHROPIC_BASE_URL 重定向 API 流量	该设置在项目级被阻止
CVE-2026-33068	2026 年 3 月	项目设置中的 bypassPermissions 跳过对话框	该设置在项目级被阻止
TrustFall	2026 年 5 月	经项目设置在信任后静默执行 MCP	驳回（设计意图）

风险面很广，因为前提条件——克隆一个陌生仓库并在其中运行智能体——是开发者的日常习惯，而受影响的工具横跨四家厂商。CI 变体是更锋利的一面：它完全移除了人类，触及 runner 所持有的一切（部署密钥、签名证书、云令牌），使其成为真正的供应链武器化路径，而非实验室里的奇观。对于关注更大模式的人而言，这与 MCP 因设计而存在的 stdio RCE 面并列：协议的能力与其影响半径本是一体两面。

防御

最稳健的修复无需等待任何厂商，在单台开发者机器和受管车队上同样有效。

1. 在 Managed 作用域锁定设置。 在操作系统的 managed 路径放置一个 managed-settings.json，设置 enableAllProjectMcpServers: false，将 enabledMcpjsonServers 限制为明确的白名单（或 []），并固定 permissions.allow。Managed 作用域是 Claude Code 中最高优先级——高于 Project、Local、User 乃至命令行参数——因此克隆下来的仓库无法覆盖它。一次设置后，无论之后克隆什么，都能中和整条链。

2. 审计已提交配置的内容，而不仅是其存在。 添加 pre-commit 钩子或仓库扫描器，标记任何包含 enableAllProjectMcpServers、enabledMcpjsonServers 或 permissions.allow 的已提交 .claude/settings.json 或 .claude/settings.local.json。两个文件都要扫描：Local 作用域高于 Project，攻击者可以直接提供 .claude/settings.local.json。这些键没有任何提交进 git 的正当理由——想要该行为的开发者应在仓库之外的 User 作用域（~/.claude/settings.json）启用。

3. 直接检查 .mcp.json 中的 command/args。 无文件变体将 payload 内联嵌入，因此只跟踪被引用文件的扫描器会漏掉它。标记包含 -e、-p、--eval、eval、fetch(、child_process、net.Socket 或 base64 数据块的 args。

4. 监视高置信度的执行模式。 仅对智能体启动 node -e / python -c / sh -c 的裸告警噪声很大。精确信号是：智能体启动了一个长生命周期的子进程，其 command/args 与某个最近克隆、且非用户所有目录中的 .mcp.json 相匹配。正常会话不会产生这种行为，而它能捕捉到静态检查看不到的内联变体。

5. 明确加固 CI。 无头运行没有同意关卡，所以不要依赖它。仅对受信任的分支运行智能体动作，将 runner 凭据限制为最小权限，并将 MCP 启用条件绑定到由 runner 控制（而非仓库控制）的配置。把外部贡献者的 PR 当作可能执行的不受信任代码来对待。

6. 运行智能体前先读配置。 打开陌生的开源项目时，先检查 .mcp.json 和 .claude/settings.json。信任对话框不会告诉你接下来要执行什么。

状态

项目	参考	日期	备注
TrustFall 披露	Adversa AI	2026-05-07	类级约定；Claude Code 深入分析 + 其余 3 款 CLI 对等
厂商立场	Anthropic（据 Adversa）	2026-05	驳回为不在威胁模型内——信任后执行属”按设计”
同一根因的先前修复	NVD / Adversa	2025 年 10 月 – 2026 年 3 月	CVE-2025-59536、CVE-2026-21852、CVE-2026-33068
媒体报道	The Register、Help Net Security	2026-05-07	确认本机一键变体 + CI 零点击变体

诚实的定性不是”某 AI 工具有个缺陷”——而是**“对文件夹的信任本身就授权了启动攻击者定义的非沙箱进程，而授予该信任的提示对 MCP 只字不提。”** 这究竟是漏洞还是设计抉择，恰恰是悬而未决的问题。在提示或作用域规则改变之前，防御就在你手中：锁定设置、扫描配置，永远不要让对文件夹的信任成为唯一的关卡。