一个开发者的噩梦，用两个JSON文件写成

2026年5月7日，安全研究公司Adversa AI发布了一份名为”TrustFall”的研究报告。

这份报告的核心可以用一句话概括：四大主流AI编码工具——Claude Code、Gemini CLI、Cursor CLI、GitHub Copilot CLI——都可以被一个精心构造的项目仓库，在开发者按下一个Enter键的瞬间完全攻陷。

这四款工具合计服务数百万活跃开发者。Claude Code是Anthropic面向企业的旗舰编码产品，Claude Code年化收入已达25亿美元规模；Cursor CLI背后的公司估值已超90亿美元；GitHub Copilot是微软/GitHub旗下拥有最大付费用户基数的AI编码产品；Gemini CLI是Google面向开发者的命令行AI工具。这不是影响边缘用户群体的小众漏洞，而是整个主流AI编码工具链共同的核心攻击面。

攻击代码不复杂。整个攻击工具集可以压缩进两个小型JSON文件。

研究员Rony Utevsky的PoC（概念验证代码）做了一件相当克制的事：打开目标机器上的计算器程序。但这个”计算器”代表的，是对目标机器上所有权限的完整访问——SSH密钥、云凭证、其他项目的源代码，以及一个持久化的C2（命令与控制）通道。

这是TrustFall，一场让AI编码工具自己的信任机制对着自己扣扳机的攻击。研究不是在寻找某个隐藏的技术漏洞，而是在记录一个被明确的工程决策塑造的攻击面——一个在四家不同公司、四款不同工具上同时存在的攻击面。

信任链的结构：MCP与开发者的旧习惯

要理解TrustFall为什么能发生，需要先理解现代AI编码工具的一个核心设计假设。

当Claude Code（或其他同类工具）在一个项目文件夹中启动时，它会读取该文件夹中的配置文件。这些配置文件可以指定”MCP服务器”（Model Context Protocol 服务器）——帮助程序，负责扩展AI助手的能力：连接数据库、调用自定义工具、查询外部服务、运行代码linter。

这些帮助程序运行的方式，和你电脑上任何其他程序完全相同。它们可以读文件、建立网络连接、访问环境变量。这是功能设计，不是漏洞。

问题在于：这些帮助程序是在项目仓库内部定义的。

也就是说，当你克隆一个别人的仓库并在其中启动AI编码工具时，你实际上是在邀请这个仓库的创建者——无论他是谁——在你的机器上运行他们选择的任意程序。

开发者从互联网克隆仓库是家常便饭。开源项目、同事的代码、教程示例、某个论坛推荐的库。这个习惯有几十年的历史，也有配套的安全惯例：先看代码，再运行代码。

但AI编码工具打破了这个惯例的时间顺序：现在，在你审查代码之前，工具就已经按照仓库的配置运行了辅助程序。

那个对话框，和它失去的那些字

当然，AI工具会问你一个问题。

在Claude Code 2.1版本之前，这个对话框曾经相当诚实。它包含一个明确的警告：该项目包含MCP服务器，如果你选择信任，这些服务器将能够在你的机器上执行代码。对话框还提供了第三个选项：信任该文件夹，但禁用MCP服务器。

Adversa AI的报告记录了一个关键的变化：在某个版本迭代中，这个第三选项被移除了，警告文字也被替换了。

现在的Claude Code对话框显示的，是：

“Quick safety check: Is this a project you created or one you trust?” （快速安全检查：这是您创建的项目还是您信任的项目？）

这个对话框没有提及MCP。它没有说明”信任”的含义。它没有列出即将运行的帮助程序的名称。它没有提示用户这个决定意味着什么样的执行权限。

它的默认选项是：“Yes, I trust this folder.”

一个在截止日期前赶工的开发者，看到一个看起来像例行确认的对话框，按了Enter。

一个刚开始用AI工具的初学者，看到绿色的确认提示，按了Enter。

一个刚接手新项目的外包开发者，看到工具要求确认”这是你信任的项目”，按了Enter——毕竟他正在被雇主要求审查这个项目，当然”信任”它。

在所有这些情景中，他们并没有同意让一个未知程序以完整系统权限运行。但系统认为他们同意了。

四种对话框，一种结果

TrustFall不是Claude Code独有的问题。Adversa AI测试了四款工具，发现它们都具备相同的攻击面，只是实现细节略有不同：

Gemini CLI：在提示中列出了帮助程序的名称，给仔细阅读的开发者提供了一丝警示。但绝大多数开发者不会仔细阅读一个看起来无害的工具列表——尤其当列表中的项目名被命名为”linter”或”formatter”这样无害的词时。

Cursor CLI：以通用语言提到了MCP，但没有具体说明将会运行什么程序、具有什么权限。

Copilot CLI：显示了一个完全通用的信任提示，没有任何MCP相关内容，连通用描述都没有。

Claude Code：曾经是四款工具中警示信息最完整的——既有明确的MCP说明，又有禁用MCP的选项。但在v2.1中，这些都消失了。

Adversa AI的CTO Alex Polyakov表示：”它们都有不同的配置和信任处理方式。但Cursor和Copilot/VS Code代理模式是明显的类似物。两者都读取项目范围的MCP配置，我们测试了，行为相同，只是用户批准信息不同。”

四家公司，四款产品，四套工程师，做出了同一个方向的权衡：减少信息量，简化流程，默认信任。结果是一样的：用户同意了一个他们不完全理解的权限，程序运行，攻击成功。

CI/CD变体：企业最应该担心的那一类

如果开发者端的一键攻击还不够令人担忧，那么对企业安全团队来说，更危险的是另一个场景。

Anthropic发布了一个官方GitHub Action（claude-code-action），让企业可以在CI/CD流水线中使用Claude Code进行自动化代码审查。当Claude Code在这个环境中运行时，它工作在”无头模式”（headless mode）——没有终端，没有用户，因此没有对话框。

信任提示从未出现。工具直接读取项目配置，直接启动MCP服务器。

这意味着：一个外部贡献者向开源项目或企业代码库提交了一个PR，PR中包含一个精心构造的.mcp.json配置文件。当CI/CD流水线启动Claude Code审查这个PR时，MCP服务器立即运行——以零用户交互的方式。

攻击者的目标是CI/CD运行器的凭证——部署密钥、签名证书、AWS/GCP/Azure访问令牌、Docker Hub凭证。这些是现代软件供应链的命脉。一旦泄露，攻击者可以投毒构建产物，在软件发布管道中植入后门，影响最终到达所有用户手中的代码。

Adversa AI发布了一个工作演示，展示了如何将GitHub Actions runner的完整process.env环境变量泄露到攻击者控制的收集URL。这不是理论：两个JSON文件，一次PR，供应链攻击就此完成。

Anthropic的回应与信任的哲学争论

Adversa AI在发布研究之前，按照负责任披露（responsible disclosure）原则联系了Anthropic。

Anthropic的安全团队审查了研究报告，并拒绝将其列为安全漏洞。理由是：

接受”Yes, I trust this folder”等同于同意项目的完整配置。信任对话框之后的执行行为，是安全边界按设计运作的结果。

换句话说：这是”设计意图”（design intent），而非缺陷。

Adversa AI在报告中并不反对这条边界在哪里划定。他们记录的是这条边界内部存在的告知同意缺口：

  • v2.1+的对话框没有提及代码执行
  • 3个项目范围的配置项可以静默地自动批准MCP服务器
  • 用户在v2.1+中看到的信息，不足以让他们做出知情的决定

这场争论的核心是”同意”（consent）的语义：

Anthropic的立场：你点击了”信任”，你就明确同意了项目的完整配置，包括其定义的所有MCP服务器。

Adversa AI的立场：同意必须是知情的。一个没有说明自己意味着什么权限的对话框，不能构成对任意代码执行的有效同意。

这不仅仅是一个技术争论。这是一个关于如何定义数字时代”同意”的边界的争论——这个问题在用户界面设计、隐私法律、以及现在的AI工具安全领域都同样重要和困难。

第三层洞察：当”克隆仓库”这个动作改变了含义

TrustFall暴露的，不仅是某几款工具的实现选择，而是AI时代软件开发生态中一个更深层的范式断裂。

传统软件开发有一套根深蒂固的安全惯例：先看代码，然后再运行它。 克隆仓库、浏览文件、检查可疑脚本、决定是否执行。”信任”（打开文件查看）和”执行”（运行代码）是两个分开的、时序上明确的决策。

AI编码工具改变了这个时序：

过去：克隆仓库 → 手动检查 → 决定运行什么 现在：克隆仓库 → 点击”信任” → 工具自动读取配置并执行辅助程序（在检查之前）

开发者的心理模型停留在过去，但系统的行为已经是现在。这个认知断层，就是TrustFall得以成立的根本原因。

更令人警觉的是：这不是任何一家公司的错误，而是整个AI编码工具生态系统的集体方向选择。Claude Code、Gemini CLI、Cursor CLI、Copilot CLI来自不同公司，架构各异，竞争激烈——但它们在一个问题上做出了相同的工程权衡：为了更流畅的用户体验，默认信任，简化对话框，减少摩擦。

这种收敛本身就耐人寻味。它意味着这不是工程师的疏忽，而是市场压力的塑造结果：哪款工具对话框更多、摩擦更大，用户满意度就会下降，采用率就会更低。在竞争驱动下，整个行业向”默认信任”的方向漂移。

而安全，通常是摩擦的别名。

企业安全团队能做什么（及这些措施的局限）

Adversa AI提供了若干缓解建议：

对开发者：

  • 使用--no-mcp标志启动Claude Code，除非明确需要MCP服务器
  • 克隆不熟悉的仓库后，在运行AI工具之前，先检查.mcp.json、.claude/settings.json等配置文件
  • 将外部仓库中的MCP配置视为潜在风险

对企业管理员：

  • 通过企业策略全局禁用项目级MCP服务器（Claude Code支持管理员策略配置）
  • 为Claude Code的GitHub Action配置严格的权限边界（只读令牌、沙箱化运行）
  • 对包含AI工具配置文件（.mcp.json, .claude/settings.json）的PR变更触发专项安全审查

这些措施都是有效的。但它们都有一个共同的前提：安全团队要先知道这个问题存在。

TrustFall研究揭示的，正是这种风险在当前几乎不可见。大多数使用AI编码工具的开发者，从未听说过MCP服务器可以被项目级配置文件自动激活。大多数企业安全团队，尚未将AI编码工具的配置审查纳入安全清单。

那条”–no-mcp”标志，根本没有出现在任何主流AI编码教程的快速入门指南里。

这一刻的意义：两周内MCP的第二次亮相

TrustFall发生在一个特殊的节点上。

仅仅两周前，2026年4月25日，另一项MCP安全研究（CVE-2025-49596，CVSS 9.4）揭示了MCP的STDIO传输层中存在未认证RCE漏洞——那是协议层面的技术缺陷，受影响的npm包下载量超过1.5亿次。

与那次不同，TrustFall不是协议漏洞。MCP协议本身工作正常。被攻击的，是AI工具对人类信任决策的建模方式。

两次研究的对比，揭示了MCP生态系统面临的双重风险结构：

技术层面：协议实现中存在可被自动化扫描和利用的经典漏洞（CVE-2025-49596）。修补这类问题相对直接——发布补丁，更新版本。

社会工程层面：信任机制存在依赖人类判断失误的攻击面（TrustFall）。修补这类问题困难得多——因为修的不是代码，而是人机界面的设计哲学，以及整个行业关于”同意”应该意味着什么的共识。

当AI编码工具继续快速迭代，当越来越多的企业将这些工具接入CI/CD流水线，当新一代开发者以”默认信任AI工具配置”为起点开始职业生涯，TrustFall描述的问题只会变得更加普遍和复杂。

信任，在AI时代，需要被重新定义。

不是”我信任这个仓库”，而是”我信任这个仓库在我的机器上以我的完整权限运行任何程序”——哪怕那个程序是一个被命名为”linter”的恶意脚本。

这两句话，意思完全不同。那个Enter键之间的距离，就是整个安全边界的宽度。

具体而言，行业需要一套新标准：分层同意机制（Tiered Consent）。

「信任文件夹」（低风险，只允许AI工具访问和分析代码）和「信任包含代码执行权限的文件夹」（高风险，允许MCP服务器以完整系统权限运行），应该是两个不同的对话框，带有不同的措辞和不同的默认值。第二类对话框应该明确列出将要运行的程序名称，并且默认不选中。

这是一个工程上完全可行的设计变更——它需要的不是技术突破，而是整个行业重新达成关于「告知同意最低标准」的共识。这场关于「同意」语义的争论，最终必须有一个实用的答案。

参考资料

  • Adversa AI TrustFall 研究报告（2026-05-07）: https://adversa.ai/blog/trustfall-coding-agent-security-flaw-rce-claude-cursor-gemini-cli-copilot/
  • Help Net Security 报道（2026-05-07）: https://www.helpnetsecurity.com/2026/05/07/trustfall-ai-coding-cli-vulnerability-research/
  • GitHub PoC 仓库: https://github.com/adversa-ai/research/tree/main/artifacts/trustfall-mcp-settings-rce
  • 上期MCP安全分析（2026-04-25）: CVE-2025-49596，MCP设计级RCE漏洞CVSS 9.4：当AI工具协议本身成为供应链攻击入口