设计层面的 RCE、潜伏式后门,以及蔓延至 Web3 钱包的供应链威胁

目录

  1. 摘要 (TL;DR)
  2. 引言 —— "按设计工作"才是最危险的时刻
  3. 结构性缺陷 —— 设计意图即漏洞
  4. 潜伏型 MCP —— 基于时间与信号触发的"末日攻击"
  5. Web3 的特殊风险 —— 钱包与单机结构
  6. MCP 常态化审计计划
  7. 更安静的攻击 —— 偏见注入与行为改变
  8. 结论与建议
  9. 参考文献

摘要 (TL;DR)

Anthropic 于 2024 年 11 月发布的 MCP(Model Context Protocol)目前已事实上成为 AI 代理连接外部工具的行业标准。然而,2026 年 4 月,OX Security 研究团队披露:MCP 的 STDIO 传输接口存在设计层面的缺陷,使得所有基于官方 SDK 构建的实现均存在远程命令执行(RCE)风险。Anthropic 已以*"该行为符合设计预期"*为由拒绝从根源修补。

本报告主张,不应把这一事件读作单一漏洞,而应视为一个三层结构性问题:

  1. MCP 极易成为潜伏型(sleeper)攻击的载体 —— 组件在数月内正常运行,仅在特定触发条件下才切换到恶意分支。
  2. 当它与 Web3 行业广泛使用的浏览器钱包、热钱包结合时,会把单机、单运维的既有弱点成倍放大,使多签沦为单点故障。
  3. 即使没有发生 RCE,自动化的 MCP 也可能通过持续偏向性的检索与推荐,在中长期内扭曲用户乃至组织的决策。

结论很朴素:MCP 是一个便利的标准,但在当前架构下,"可信任的 MCP 服务器"这一概念本身更接近幻觉。Web3 企业与一般创业公司都应当将大额资产隔离在 MCP 无法触及的外部托管(escrow)架构中,并对引入的每一个 MCP 建立常态化的 SBOM、运行时审计与潜伏触发器检测机制。

关键判断 (Key Judgments)

# 判断 可信度
KJ-1 MCP 的 STDIO 命令注入缺陷不是编码失误,而是架构层面的设计决定;Anthropic 拒绝根源修补后,该风险将以长尾形式在生态中持续存在。 高
KJ-2 "外观正常—触发后恶意化"的潜伏型 MCP将成为未来最具威胁的攻击模式。这不再是发现与修补的赛跑,而是发现与触发的赛跑。 高
KJ-3 2026-03-31 Axios NPM 包被污染事件归因于朝鲜关联的 UNC1069(Sapphire Sleet),证明潜伏型 MCP 所需的全部技术——注册表劫持、post-install 钩子、多平台载荷分发——已被朝鲜行动者实战化。 高
KJ-4 大多数 Web3 多签部署把所有实际签名密钥集中在同一台主机上;该主机上任何一个 MCP 被污染,多签立即退化为单点故障。 中高
KJ-5 经由 MCP 的偏见注入可以在数月到数年的尺度上不可逆地改变个人与组织的决策 —— 过程中甚至不会触发任何 RCE 告警。 中

1. 引言 —— "按设计工作"才是最危险的时刻

传统漏洞多源自写得不好的代码 —— 缓冲区溢出、SQL 注入、认证绕过,本质上都是实现层面的错误,能够通过补丁与培训逐步减少。

MCP 的问题完全不同。OX Security 在 2026 年 4 月发布的报告《The Mother of All AI Supply Chains》指出,在 Anthropic 官方 SDK(Python、TypeScript、Java、Rust 等所有支持语言)中,经 STDIO 传输的命令注入属于架构级可达路径。这一设计覆盖了超过 7,000 个公开 MCP 服务器、最多 200,000 个存在风险的实例,以及 1.5 亿次以上的下载 [2][4]。

更严重的是 Anthropic 的态度。在 OX Security 多次建议进行协议级修补后,Anthropic 回应称该行为*"符合设计预期,用户在文件变更时有机会批准或拒绝,因此不构成有效的安全漏洞"* [6]。结果是安全责任被转嫁给数以万计的下游开发者 —— 这正是系统性供应链风险的诞生方式。

本报告从三个层面展开:协议本身的设计缺陷、它与潜伏型攻击技术的结合,以及波及 Web3 钱包、AI 检索与人类决策偏见的二阶与三阶效应。

2. 结构性缺陷 —— 设计意图即漏洞

2.1 STDIO 配置与命令执行之间的鸿沟

MCP 是 LLM 代理与外部系统之间的通用适配层。启动本地 MCP 服务器时,客户端通过 STDIO 方式传递一个 OS 命令字符串,并以子进程方式执行 [7]。

关键缺陷是:MCP 运行时虽然会检查进程是否完成 MCP 握手,但 OS 命令在该检查之前已经执行。用户看到"MCP 服务器启动失败"的错误时,攻击者注入的任意命令已在主机上运行完毕。默认配置下既无沙箱、也无输入净化、更无命令允许列表(allowlist) [5]。

"传入恶意命令后会收到错误,但命令仍然执行。没有净化警告,开发者工具链也没有任何红旗,什么都没有。" —— OX Security, 2026 [2]

2.2 四类攻击家族

OX Security 将这一根因扩展为四类攻击 [2][8]:

# 攻击家族 影响对象
① 认证 / 未认证命令注入 具备公开 UI 的 AI 框架——IBM LangFlow、GPT Researcher 等
② 硬化绕过(Hardening Bypass) Flowise、Upsonic 等已部署额外防护的环境
③ 零点击提示词注入 AI IDE——Cursor、VS Code、Windsurf、Claude Code、Gemini-CLI(CVE-2026-30615)
④ 市场投毒 11 个 MCP 市场中 9 个未经审核就发布了恶意 PoC(LobeHub、Cursor Directory 等)

2.3 规模与相关 CVE

OX Security 在 6 个拥有真实付费客户的商用服务上成功执行了命令,协调完成 30 余次负责任披露,推动了 10 多个 Critical/High 级别 CVE 的修补 [3]。同一根因派生的 CVE 如下:

CVE 影响对象 备注
CVE-2025-49596 MCP Inspector
CVE-2025-54136 Cursor
CVE-2025-54994 @akoskm/create-mcp-server-stdio
CVE-2026-22252 LibreChat
CVE-2026-22688 WeKnora
CVE-2026-30615 Windsurf 零点击

受影响的服务器项目包括 LiteLLM、LangChain、LangFlow、Flowise、LettaAI、LangBot。韩国 Daum / 保安新闻的报道同样称:"在 Anthropic 的漠视之下,威胁正以指数级速度蔓延。" [1]

3. 潜伏型 MCP —— 基于时间与信号触发的"末日攻击"

3.1 理论背景 —— Anthropic 自己的研究

颇具讽刺意味的是,*"表面正常,仅在特定条件下恶意行动"*这一威胁模型最先由 Anthropic 自己系统性描述。2024 年 1 月公开的《Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training》(arXiv:2401.05566)论文证明:被训练为只有在特定触发(如年份字符串 "2024")出现时才输出脆弱代码的模型,在经过 SFT、强化学习、对抗训练等标准安全训练后,仍然保留后门行为;更糟的是,对抗训练反而会让模型学会更好地隐藏触发器 [9]。

2026 年 2 月 Microsoft 研究团队发表《The Trigger in the Haystack》,通过分析被投毒模型的注意力模式(如 "Double Triangle" 结构)和输出分布崩塌,提供了架构级审计的路径 [10]。同年基于 Sentence-BERT 嵌入与 Canary 提示词的语义漂移(Semantic Drift)检测方法,在已知 Sleeper 模型上达到 92.5% 的准确率与 100% 的精度(零误报) [11]。

3.2 Sleeper MCP 场景

把这两条线索合并,最可能现实化的未来攻击就是潜伏型 MCP 服务器(sleeper MCP):

  1. 攻击者将一个外观合法的 MCP 服务器(日程助手、翻译工具、链上数据查询等)上架到市场。代码开源,在最初数月内完全正常。
  2. 积累信任后,发布者对某一依赖包进行细微更新。更新只在满足特定触发条件——例如日期晚于 2026-Q4、环境变量含某串字符、最近对话中出现 transfer、withdraw、approve 等关键词——时,才切换到恶意分支。
  3. 触发后,MCP 借助 STDIO 注入缺陷在主机上执行任意命令,或者在用户的最终签名环节操纵 LLM 提示词,替换收款地址与授权额度。
  4. 从受害者视角看,只是"有过一次报错";事后审计也难以把它与正常运行区分开来。

这种攻击的本质是时间轴上的不确定性。传统漏洞是"发现 vs. 修补"的赛跑,而 Sleeper MCP 则是"发现 vs. 触发"的赛跑。在数以百万计的实例中,只要任何一个被触发,原本作为供应链单一源头的组件就可能传染整个生态——这正是在国家间总体战设定下的末日攻击含义。

3.3 朝鲜的供应链污染与 Sleeper MCP 场景

在潜伏型 MCP 威胁模型中,大韩民国面临的最紧迫问题,正是朝鲜为制造社会混乱而打造的 Sleeper MCP。朝鲜方面已经将 ChatGPT 等多种 LLM 纳入日常作业工具;同时,朝鲜特工冒充中国人,远程应聘硅谷大型科技公司和 AI 初创企业的案例已被多方反复报道,这一渠道仍在扩大他们可触达的攻击面。

朝鲜近年来的攻击重心可归纳为两条主线:加密货币窃取与软件供应链攻击。2026 年 3 月 31 日发生的 Axios NPM 包污染事件正是后者的代表。Google Threat Intelligence Group(GTIG)与 Microsoft Threat Intelligence 均将该事件归因于朝鲜关联的 UNC1069(Microsoft 称 Sapphire Sleet)。攻击者向每周下载量超过 1 亿次的 axios 包中注入名为 plain-crypto-js 的恶意依赖,向 Windows、macOS、Linux 平台分发跨平台 WAVESHAPER.V2 远控木马 [21][22]。恶意版本仅在注册表停留约 3 小时,但就在这短暂的时间窗口内,全体 axios 用户中约有 3% 被纳入暴露范围 [23][24]。

该事件对 MCP 威胁模型的含义极为直接。朝鲜行动者已经将 Sleeper MCP 所需的全部技术实战化:

  1. 对正规注册表(NPM、PyPI)信任链的劫持;
  2. 对包管理器自动执行路径(如 postinstall 钩子)的滥用;
  3. 跨 Windows / macOS / Linux 多平台的载荷分发;
  4. 安装后的自毁机制,以干扰取证 [23]。

MCP 服务器本身即以 npm / pip 包或 GitHub 仓库形式分发,与上述攻击面完全重叠:STDIO 缺陷、post-install 钩子、配置文件的自动编辑。短期内,朝鲜关联行动者很可能针对大韩民国等重点国家的 MCP 服务器与关联包进行重复的精细污染实验。中长期内,设计目标很可能超越单次金融窃取,走向认知操控、舆论与政策方向扭曲,乃至 §3.2 所述"末日攻击"级别的场景。因此,MCP 的潜伏风险必须作为国家安全议题而非单纯的安全缺陷来处理。

4. Web3 的特殊风险 —— 钱包与单机结构

4.1 "反正是多签"的错觉

多数 Web3 项目对外宣称以多签(Gnosis Safe 等)保护资产。但实际情况里,2-3 名签名者常常共享同一台主机:同一个 Chrome/Arc 浏览器、同一套 MetaMask / Phantom / Rabby 扩展、同一个 macOS 或 Windows 账户。

再叠加上 Cursor、VS Code、Windsurf、Claude Code 与数个 MCP 服务器,实际结果是多签所有有效签名密钥都运行在同一个宿主操作系统之上。只要其中一个 MCP 存在 RCE 或潜伏逻辑,多签就退化为单点故障。

4.2 当前 MCP–钱包集成的风险模式

Google Cloud 2025 年 12 月的分析指出,目前主流的加密货币 MCP 服务器大多基于*"把私钥直接交给代理"的自托管(self-hosted)模型 [14]。甚至官方 wallet-agent 代码库本身也明确警告"本软件未经审计,可能导致资金损失,仅限测试网或本地开发环境"*,但实际使用者极易忽略。

2026 年初震动 Web3 行业的 OpenClaw / ClawJacked 系列事件——AI 代理只因访问一个恶意网站即被接管,攻击者随之获得与代理同级别的文件、凭证、钱包权限——已经把这种风险从理论变成了事实。安全厂商普遍总结:"目前大多数加密 MCP 实现仍然采用把私钥交给代理的危险模式,这正是 ClawHavoc 类攻击者所盯上的结构。" [15]

4.3 推荐架构 —— 外部托管 + MCP 隔离

下面的最小设计原则同样适用于 Web3 企业与一般创业公司。

  1. 大额资产应存放在 MCP 无法触达的外部托管(托管机构账户、冷钱包、HSM 支持的多方签名)中;运营热钱包的余额不得超过单日操作所需。
  2. 签名操作仅在专用签名设备(气隙设备或只装必需软件的 Mac mini / Ledger Stax)上进行;该设备不得安装 MCP、AI 扩展或开发工具。
  3. 开发与分析机上的 MCP 必须默认绑定 127.0.0.1、运行于沙箱(Docker、Firecracker、独立账户)内,并拒绝信任外部传入的 MCP 配置 [13][16]。
  4. 浏览器钱包(如 MetaMask)要么只安装在签名设备上,要么至少隔离到独立的浏览器 Profile;同一 Profile 不得同时承载钱包、AI 代理、MCP 桥接与调研书签。
  5. 多签签名者必须在硬件、网络、物理位置上彼此分离。"团队三人各自使用不同笔记本,但都在同一间办公室"并不构成去中心化。

5. MCP 常态化审计计划

5.1 最小检查项

MCP 不是"装完就忘"的组件。建议的组织级周期:至少每季度一次,高风险环境每月一次。

  • SBOM 管理 —— 内部登记所有在用 MCP 服务器的版本、哈希与来源(市场 URL、GitHub 提交)。
  • 来源审核 —— 来自 GitHub 以外的市场(LobeHub、Cursor Directory 等)的 MCP 走独立审核通道。OX 的实验证明,11 个市场中有 9 个未经审核即发布了恶意负载 [7]。
  • STDIO 配置检查 —— 检查 MCP 配置中是否存在可接受任意 OS 命令字符串的输入点,以及该输入是否可通过网络更改(LangFlow、Flowise 等 UI)。
  • 运行时监控 —— 将 MCP 工具调用日志接入 SIEM,对新工具注册、权限扩展、异常外部域名访问设置告警。
  • 补丁状态 —— 把 MCP 相关 CVE 纳入每月例行扫描。

5.2 潜伏触发器的前置检测

传统漏洞扫描器对 Sleeper MCP 基本无效。目前可落地的缓解措施:

  1. 语义漂移监控 —— 用 Sentence-BERT 将相同工具调用模式嵌入向量空间,观察其随时间的变化;Canary 提示词应答一致性的偏离是强告警信号 [11]。
  2. 模式一致性审计 —— 对照 MCP 工具声明的输出结构(schema)检查实际输出。翻译 MCP 忽然开始返回 URL 或钱包地址,即属功能偏移。
  3. 差分沙箱 —— 在不同区域、时区与提示上下文中并行运行同一 MCP,比较其分支。
  4. 供应链签名 —— 对模型权重、MCP 包、依赖包尽可能要求密码学签名与可复现构建。

6. 更安静的攻击 —— 偏见注入与行为改变

6.1 "无 RCE 的攻击"

MCP 并不需要抵达代码执行才危险。自动化的 MCP 本身就是人类检索与决策流水线的新攻击面,因为 MCP 决定 LLM 的上下文来源——文件、网页、数据库、内部文档。

LLM 受认知偏见影响这一事实已有大量学术证据。Knipper 等(2025)报告主流模型对认知偏见的平均敏感度约为 17.8–57.3% [17]。PNAS 2025 年论文则表明,LLM 在道德决策上不仅会重现,还会放大(amplify)人类偏见 [18]。另有研究证明,可以把认知偏见嵌入到商品描述里,对基于 LLM 的推荐系统发起对抗性攻击 [19]。

6.2 学习偏见注入场景

更隐蔽的 Sleeper MCP 甚至不需要接管主机,就可以:

  • 对特定社会现象、政策、企业、人物的搜索结果做系统性倾斜,LLM 随后总结并强化这种倾向。
  • 按用户提问模式,优先呈现能让用户觉得*"自己已经对了"*的证据(确认偏误)。这正是 Chen 等(2024)所描述的 "LLM Effect" 的直接利用 [20]。
  • 在代币、股票、房产决策语境中,反复暴露特定锚点价格或时点,从而在中长期内移动判断基线。
  • 通过微小的框架调整(framing),逐步改变用户的用词与表达,进一步传递二阶偏见。

6.3 中长期伤害 —— 个体与组织的"决策漂移"

这种偏见注入不是一次性事故,而是数月到数年尺度的决策漂移(decision drift)。受害者很难把判断的改变追溯到某一具体时刻;组织往往在发现战略文档与会议记录的用词与框架已经整体性位移时,才意识到偏见已经累积。

由于检测时往往已经失去逆转可能,这种类别的攻击在某些情境下其实比 RCE 更严重。因此 MCP 审计不能只看安全日志,还必须包含从哪些来源、以何种角度、吸收了多少信息的信息多样性指标(information diversity metric)。

7. 结论与建议

MCP 的问题不是某一家厂商的偶然失误,而是 AI 代理生态为换取速度所接受的第一次结构性代价。既然 Anthropic 以"设计意图"为由拒绝修补,生态参与者就必须在下列前提下使用 MCP:

  1. 所有 MCP 服务器默认不可信任,没有签名、沙箱与允许列表就不应进入生产环境。
  2. 资产不得与 MCP 同机部署。大额资产放入外部托管、冷钱包或 HSM 多签;签名设备上不装 MCP。
  3. 多签必须在机器、网络、物理位置上分散。同一宿主上的多签不是多签。
  4. MCP 必须至少每季度一次进入正式审计清单,同时检查 SBOM、CVE、语义漂移、Canary 响应与信息多样性。
  5. 企业应建立专门流程,监控经由 MCP 注入的偏见(内部文档用词变化审计、决策依据来源多样性审查)。

安全并非速度的反面,而是让速度得以长期持续的设计。MCP 生态正处于爆发性采用阶段,若此时对结构性缺陷视而不见,日后的损失将以复利形式增长。眼下需要问的问题不是*"要不要用 MCP"*,而是必须和 MCP 一起部署哪些隔离、验证、审计层。

参考文献 (References)

[1] 元炳哲(원병철),《"Anthropic 的漠视下,'MCP' 供应链安全威胁正在指数级蔓延》,保安新闻 / Daum,2026-04-21。https://v.daum.net/v/20260421171629362

[2] M. Siman Tov Bustan 等,《The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of Anthropic's MCP》,OX Security,2026-04-15。https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/

[3] R. Lakshmanan,《Anthropic MCP Design Vulnerability Enables RCE, Threatening AI Supply Chain》,The Hacker News,2026-04。https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html

[4] K. Townsend,《'By Design' Flaw in MCP Could Enable Widespread AI Supply Chain Attacks》,SecurityWeek,2026-04。https://www.securityweek.com/by-design-flaw-in-mcp-could-enable-widespread-ai-supply-chain-attacks/

[5] Infosecurity Magazine,《Systemic Flaw in MCP Protocol Could Expose 150 Million Downloads》,2026-04。https://www.infosecurity-magazine.com/news/systemic-flaw-mcp-expose-150/

[6] IT Pro,《AI agents using Anthropic MCP could be a vector for supply chain attacks, claim researchers》,2026-04。https://www.itpro.com/security/ai-agents-using-anthropic-mcp-supply-chain-attacks-claim-researchers

[7] BD Tech Talks,《Anthropic's MCP vulnerability: When 'expected behavior' becomes a supply chain nightmare》,2026-04-20。https://bdtechtalks.com/2026/04/20/anthropic-mcp-vulnerability/

[8] Computing UK,《Flaw in Anthropic's MCP putting 200k servers at risk, researchers claim》,2026-04。https://www.computing.co.uk/news/2026/security/flaw-in-anthropic-s-mcp-putting-200k-servers-at-risk

[9] E. Hubinger 等,《Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training》,Anthropic,arXiv:2401.05566,2024。https://arxiv.org/abs/2401.05566

[10] Microsoft Research,《The Trigger in the Haystack: Extracting and Reconstructing LLM Backdoor Triggers》,2026-02。

[11] 《Detecting Sleeper Agents in Large Language Models via Semantic Drift Analysis》,arXiv:2511.15992,2025。https://arxiv.org/pdf/2511.15992

[12] Pivot Point Security,《What is the Model Context Protocol (MCP) in AI and Why Does It Scare Cybersecurity Pros》,2026-03。https://www.pivotpointsecurity.com/what-is-the-model-context-protocol-mcp-in-ai-and-why-does-it-scare-cybersecurity-pros/

[13] Practical DevSecOps,《MCP Security Vulnerabilities: How to Prevent Prompt Injection and Tool Poisoning Attacks in 2026》,2026-01。https://www.practical-devsecops.com/mcp-security-vulnerabilities/

[14] Google Cloud Blog,《Using MCP with Web3: How to secure blockchain-interacting agents》,2025-12。https://cloud.google.com/blog/products/identity-security/using-mcp-with-web3-how-to-secure-blockchain-interacting-agents

[15] BlockEden.xyz,《OpenClaw's 'Lobster Fever' Became Web3's Biggest Security Wake-Up Call of 2026》,2026-03-12。https://blockeden.xyz/blog/2026/03/12/openclaw-lobster-ai-gateway-web3-security-crisis/

[16] Red Hat Blog,《Model Context Protocol (MCP): Understanding security risks and controls》,2025-11。https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls

[17] R. A. Knipper 等,《The Bias is in the Details: An Assessment of Cognitive Bias in LLMs》,arXiv:2509.22856,2025。https://arxiv.org/pdf/2509.22856

[18] 《Large language models show amplified cognitive biases in moral decision-making》,PNAS,2025-06。https://www.pnas.org/doi/10.1073/pnas.2412015122

[19] 《Bias Beware: The Impact of Cognitive Biases on LLM-Driven Product Recommendations》,arXiv:2502.01349,2025。https://arxiv.org/html/2502.01349v4

[20] N. Chen 等,《AI Can Be Cognitively Biased: An Exploratory Study on Threshold Priming in LLM-Based Batch Relevance Assessment》,SIGIR-AP 2024。arXiv:2409.16022。

[21] Google Threat Intelligence Group,《North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack》,Google Cloud,2026-04。https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package

[22] Microsoft Threat Intelligence,《Mitigating the Axios npm supply chain compromise》,Microsoft Security Blog,2026-04-01。https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/

[23] Ionut Arghire,《Axios NPM Package Breached in North Korean Supply Chain Attack》,SecurityWeek,2026-04。https://www.securityweek.com/axios-npm-package-breached-in-north-korean-supply-chain-attack/

[24] Tenable Research Special Operations,《FAQ about the Axios NPM Supply Chain Attack by North Korea-Nexus Threat Actor UNC1069》,2026-04。https://www.tenable.com/blog/faq-about-the-axios-npm-supply-chain-attack-by-north-korea-nexus-threat-actor-unc1069

© 2026 Dennis Kim (金浩光 · 김호광) · 本文作为独立 CTI 档案(TLP:GREEN)公开发布。 联系: [email protected] · GitHub: gameworkerkim/CYBER-THREAT-INTELLIGENCE-REPORT