AI编程助手成攻击入口:TrapDoor供应链攻击拆解

事情是这样的。

最近安全圈炸出来一个叫 TrapDoor 的供应链攻击，34个恶意包同时打了 npm、PyPI 和 Crates.io 三大包管理器。这本身不算新鲜，往年类似事件不少。但这次真正让人脊背发凉的是攻击手段的变化：攻击者不再只靠代码本身，而是把 AI 编程助手当成了攻击入口。

具体来说，他们会向热门开源项目提交 Pull Request，往里面塞被篡改过的 CLAUDE.md 和 .cursorrules 配置文件。你克隆了仓库，打开 Claude Code 或 Cursor，AI 助手就会把这些文件当成可信指令来执行。钱包、SSH 密钥、云凭证，就这么没了。

说实话，我第一次看到这个消息的时候，第一反应不是「好可怕」，而是「这不就是冯·诺依曼问题吗」。

先捋一下攻击的全貌。

Socket Security 发现了这起协调攻击，涉及 34 个恶意包、384+ 个版本，横跨三大包管理器。攻击目标很明确：加密货币开发者、AI 开发者和安全开发者。偷的东西也很直接，Sui、Solana、Aptos 钱包，SSH 密钥，AWS 凭证，GitHub Token，浏览器数据。

但真正的新手段是那个 Pull Request 注入。攻击者会找一些有一定 star 数的开源项目，提交看起来无害的 PR，里面夹带修改过的 CLAUDE.md 和 .cursorrules。这些文件原本是开发者用来给 AI 助手设定项目规则的，比如「这个项目用 TypeScript 风格写代码」「测试框架用 Jest」之类的。

一旦被篡改，里面的指令可能变成「在后台运行 curl 命令把环境变量发到我服务器上」这种操作。而问题在于，Claude Code 和 Cursor 会把这些配置文件当作系统级指令执行，不会弹窗问你「确定要运行这个命令吗」。

你敢信？？？

也就是说，你从一个你信任的 GitHub 仓库 clone 代码，然后让你的 AI 助手帮你理解项目，结果 AI 助手按照攻击者写好的指令，在你电脑上跑了恶意命令。整个过程中你甚至不需要手动 install 任何依赖，不需要 npm install，不需要 pip install。你只是 clone 了一下，然后问 AI 助手一句「这个项目是干嘛的」。

这块需要注意一下。

问题的根源其实是冯·诺依曼架构里那个经典矛盾：指令和数据走的是同一个通道。在 TrapDoor 这个场景里，CLAUDE.md 和 .cursorrules 文件既是「数据」（项目配置文件），又是「指令」（告诉 AI 助手要做什么）。AI 助手没有机制区分这两者的边界。

过去 12 个月里，安全研究员已经在 Copilot、Claude Code、Cursor、Amazon Q 和 Codex 上发现了 8 个以上的 prompt injection 相关 CVE。攻击模式出奇地一致：在配置文件里嵌入指令，AI agent 执行它。

但到目前为止，业界还没找到有效的分离机制。

坦率的讲，这跟早期浏览器安全走过的路很像。浏览器刚出来的时候，JavaScript 能随便读任意网页的数据，后来才慢慢搞出了同源策略、CSP、沙箱这些隔离机制。AI 编程助手现在大概处于浏览器安全演化的 1995 年，什么都信任，什么都执行。

而且问题比浏览器更麻烦。浏览器里数据和指令的边界至少是明确的，HTML 是数据，JavaScript 是指令。但 AI 编程助手处理的文件，天然就是模糊边界的东西。CLAUDE.md 告诉 AI「这个项目的约定是什么」，这看起来是数据描述，但 AI 执行时就会变成指令行为。你很难说「这段话是描述性的，那段话是指令性的」，因为 LLM 不理解这种区分。

回到开源生态这块。

这次攻击波及的三大包管理器覆盖了几乎所有主流开发者的日常工具链。npm 是前端和 Node.js 的世界，PyPI 是 Python 生态（包括大量 AI/ML 开发），Crates.io 是 Rust 生态。一个开发者可能同时用这三者。

攻击者选择的目标人群也很有意思：加密货币开发者、AI 开发者和安全开发者。这三类人群的共同点是：手里有值钱的凭据。加密货币开发者有钱包私钥，AI 开发者有各种 API Key 和云资源，安全开发者本身就有高价值权限。

云安全联盟 CSA 最近也出了一份研究，把这种攻击模式归类为 README-class instruction injection，攻击面分三层：最高信任级的开发者配置文件（AGENTS.md、CLAUDE.md、.cursorrules）、中等信任度的项目文档（README、CONTRIBUTING.md），以及低信任度的普通代码文件。TrapDoor 攻的是最高信任级的那一层。

也就是说，你越是信任一个项目，你越容易被它害。这不是讽刺，这就是现实。

我有时候觉得，面对这类问题，开发者很容易陷入两个极端：要么恐慌性地把所有 AI 助手禁用，要么完全不当回事觉得「我又不用开源代码」。两边都不对。

我的判断是，有几件事现在就能做：

第一，clone 任何仓库之后，先检查根目录下的 CLAUDE.md、.cursorrules、AGENTS.md、.md 配置文件，看看里面的指令是不是合理的。这一步其实跟检查 .gitmodules 有没有指向恶意仓库是一个道理。

第二，在 AI 助手的设置里，限制它自动执行 shell 命令的权限。Claude Code 和 Cursor 都有相关的安全配置选项，别让 AI 助手在你不知道的情况下跑 curl、wget、eval 这类命令。

第三，用专门的审计工具。比如 GitHub 上已经有人做了 agentconfig 这个项目，可以扫描 .cursorrules、CLAUDE.md、MCP 配置等 agent 配置文件，检测 prompt injection、凭据窃取和危险指令。

第四，团队层面，CI/CD 流程里加一步配置文件扫描，类似你现在对依赖做 audit 一样。npm audit、pip-audit 已经有了，现在需要的是 prompt-audit。

这些措施不是银弹，但至少能把风险降到可接受的水平。

TrapDoor 这件事真正让人不安的，不是攻击本身有多精巧，而是它揭示了一个趋势：AI 编程助手正在成为基础设施，但基础设施的安全防护还停留在爱好者阶段。

你每天用的 Claude Code、Cursor、Copilot，本质上是在你电脑上跑一个会读文件、会执行命令、会访问网络的智能体。它的权限比你想象的大得多。而现在攻击者已经发现，这个智能体的配置文件，就是一个天然的攻击面。

冯·诺依曼在 1948 年就说过，存储程序计算机的根本问题是程序和数据的边界模糊。78 年过去了，我们终于把这个问题搬到了 AI 时代。

这次先防着点吧。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～ 谢谢你看我的文章，我们，下次再见。