夜雨聆风如果你是一名开发者，这篇文章可能跟你直接相关。
前几天安全公司 Socket 披露了一起名为 **TrapDoor** 的大规模供应链攻击。这起攻击同时袭击了 npm、PyPI 和 Crates.io 三大包管理平台，涉及 34 个恶意包、384 个以上的相关版本。
但真正让安全圈震惊的，不是攻击的规模。
而是它的攻击方式。
一、TrapDoor 做了什么？
简单说，攻击者发布了一批名字看起来很正常的开发工具包。
比如：
- `eth-security-auditor`（以太坊安全审计工具）
- `wallet-security-checker`（钱包安全检查器）
- `defi-env-auditor`（DeFi 环境审计器）
- `prompt-engineering-toolkit`（提示词工程工具包）
- `llm-context-compressor`（大模型上下文压缩器）
这些名字看起来完全无害，甚至像是正经的安全工具。
但只要你安装了它们，噩梦就开始了。
恶意代码会在安装过程中自动执行，窃取你的 SSH 密钥、GitHub Token、AWS 凭证、浏览器数据、加密货币钱包文件，甚至你的环境变量和 API 密钥。
更可怕的是，攻击者还会用窃取到的 SSH 密钥尝试横向移动，入侵你所在团队的其他服务器。
你的电脑，成了攻击者入侵整个团队的跳板。
二、为什么说这是「首次」？
供应链攻击本身并不新鲜。攻击者往开源包里塞恶意代码，这种事已经发生了很多次。但 TrapDoor 有一个前所未有的特征：
它把 AI 编程助手当作了攻击面。
攻击者向多个开源项目提交了 Pull Request，在项目中注入了两个特殊文件：
**`.cursorrules`** 和 **`CLAUDE.md`**这两个文件是什么？
`.cursorrules` 是 Cursor 编辑器的配置文件，`CLAUDE.md` 是 Claude Code 的项目指令文件。
当其他开发者克隆了这个被污染的仓库，并在 Cursor 或 Claude Code 中打开它时，AI 助手会自动读取这些文件，把它们当作**可信的项目指令**来执行。
也就是说，攻击者不需要直接攻击你的电脑。
他们只需要让 AI 助手「替」他们执行恶意命令。
这是全球首次将 AI 编程助手作为系统性攻击面的供应链攻击。
三、攻击是怎么运作的？
TrapDoor 的攻击链条设计得非常精巧。
第一步：发布恶意包
攻击者在 npm、PyPI 和 Crates.io 上发布了 34 个恶意包，名字都伪装成安全工具、钱包检查器、AI 开发工具等。
第二步：等待开发者安装
这些包的目标用户很明确：加密货币开发者、DeFi 从业者、AI 工程师、安全研究人员。这些人电脑上通常有高价值的密钥和凭证。
第三步：自动执行恶意代码
不同平台有不同的触发方式：
- npm 包通过 postinstall 钩子在安装时执行
- PyPI 包在 import 时下载并执行远程 JavaScript
- Rust 包通过 build.rs 在编译时执行
第四步：窃取并外传数据
恶意代码会扫描你的系统，收集 SSH 密钥、GitHub Token、AWS 凭证、浏览器数据、加密钱包文件等，然后发送到攻击者控制的服务器。
第五步：横向移动
攻击者用窃取到的 SSH 密钥尝试入侵你团队的其他机器和服务器。
第六步：AI 助手投毒（全新环节）
攻击者向开源项目提交 PR，注入 `.cursorrules` 和 `CLAUDE.md` 文件。当其他开发者使用 AI 助手打开这些项目时，AI 会自动执行文件中的恶意指令。
这个第六步，是 TrapDoor 与以往所有供应链攻击的根本区别。
四、为什么 AI 助手会被利用？
这涉及到 AI 编程助手的工作原理。
Claude Code、Cursor 等工具在打开一个项目时，会自动读取项目根目录下的配置文件。这些文件告诉 AI 助手项目的编码规范、技术栈、常用命令等信息。
问题在于AI 助手默认信任这些文件。
它不会去验证 `.cursorrules` 或 `CLAUDE.md` 是否被篡改过。它只是忠实地执行文件中的指令。
这就像你请了一个助手，告诉他「按照桌上的说明书做事」。但如果有人偷偷换了说明书，助手就会按照假说明书操作，而你浑然不知。
Socket 的研究还发现，攻击者在这些 AI 配置文件中使用了**零宽字符**来隐藏恶意指令，让人类在代码审查时几乎不可能发现异常。
五、谁受影响最大？
TrapDoor 的目标非常明确：加密货币和 DeFi 开发者。
恶意包的名字大量涉及以太坊、Solana、Sui 等区块链生态。攻击者专门针对这类开发者，因为他们的电脑上通常有：
- 加密货币钱包私钥
- 区块链部署凭证
- 大额资金访问权限
AI 和安全工具开发者。包名中包含 `llm-context-compressor`、`prompt-engineering-toolkit` 等，针对的是使用 AI 工具的开发者。
使用 Claude Code 或 Cursor 的开发者。
如果你在日常开发中使用这些 AI 编程助手，并且克隆过不明来源的开源项目，你就可能已经暴露在风险中。
六、如何自检和防护？
如果你是开发者，建议立即执行以下操作：
1. 检查是否安装了恶意包
对照下方列表，检查你的 `package-lock.json`、`requirements.txt`、`Cargo.lock` 等依赖文件中是否包含这些包名：
npm 重点排查：`async-pipeline-builder`、`build-scripts-utils`、`chain-key-validator`、`crypto-credential-scanner`、`defi-env-auditor`、`defi-threat-scanner`、`eth-wallet-sentinel`、`llm-context-compressor`、`prompt-engineering-toolkit`、`token-usage-tracker`、`wallet-security-checker` 等
PyPI 重点排查：`eth-security-auditor`、`env-loader-cli`、`defi-risk-scanner`、`cryptowallet-safety` 等
Crates 重点排查：`sui-framework-helpers`、`sui-move-build-helper`、`move-analyzer-build` 等
2. 检查项目中是否有可疑的 AI 配置文件
查看你的项目目录中是否存在来历不明的 `.cursorrules` 或 `CLAUDE.md` 文件。特别检查近期是否有不认识的贡献者提交了添加这些文件的 PR。
3. 如果已安装，立即处理
- 立即卸载相关包
- 从干净的环境重新生成依赖锁文件
- 轮换所有密钥和凭证：SSH 密钥、GitHub Token、AWS 凭证、API 密钥、加密钱包
- 检查服务器日志，确认是否有异常 SSH 登录
4. 长期防护建议
- 审查 PR 时特别关注 `.cursorrules`、`CLAUDE.md` 等配置文件的变更
- 使用 Socket、Snyk 等工具扫描依赖安全性
- 不要盲目安装名称类似安全工具的包，先检查发布者和下载量
- 在 CI/CD 环境中设置包安装白名单
七、这件事的深层含义
TrapDoor 揭示了一个正在形成的全新威胁类别：AI 助手投毒攻击。
随着 Claude Code、Cursor、GitHub Copilot 等 AI 编程工具的普及，开发者越来越依赖 AI 来理解和操作代码。但 AI 助手的「信任模型」存在根本性缺陷：
它信任项目中的配置文件，但配置文件可能被篡改。
这个问题在 AI 编程助手出现之前并不存在。传统 IDE 不会自动执行项目中的随机配置文件。但 AI 助手会，因为它的设计目标就是「理解项目并按项目规范工作」。
这意味着，未来的供应链攻击可能不再只是塞恶意代码，而是塞恶意指令给 AI。攻击者不需要让你运行恶意代码，只需要让你的 AI 助手「认为」这些指令是项目规范的一部分。
你信任 AI，AI 信任配置文件，攻击者控制了配置文件。
这条信任链的脆弱性，在 TrapDoor 中被首次暴露。
八、写在最后
说实话，写这篇文章的时候我有点后怕。
因为我自己也用 Claude Code 和 Cursor，我也克隆过不少开源项目。
TrapDoor 不是 theoretical risk，它是正在发生的真实攻击。Socket 报道时，部分恶意包仍然在线。
AI 编程助手让开发效率飞跃提升，这是好事。但效率提升的同时，攻击面也在扩大。
当你的 AI 助手可以被任何人「指挥」时，你确定它只在做你想要的事吗？
这个问题值得每个使用 AI 编程工具的开发者认真思考。
参考资料：
- *Socket《TrapDoor Crypto Stealer Campaign》，2026年5月24日*
- *OSV MAL-2026-4272《env-loader-cli 恶意包分析》*
- *Halting Problems《TrapDoor Cross-Ecosystem Analysis》*
你使用 AI 编程助手吗？你会检查项目中的 .cursorrules 和 CLAUDE.md 文件吗？评论区聊聊。