TrapDoor供应链攻击：AI助手正在成为黑客的新突破口
如果你在用 Claude Code 或 Cursor 这类 AI 编程助手，最近一定要检查一下你的项目配置。5月25日，安全研究团队 Socket 披露了一场名为「TrapDoor」的协调供应链攻击——攻击者首次把 AI 助手当作跳板，通过污染开源项目的配置文件来窃取加密货币钱包、SSH 密钥和云凭证。与传统供应链攻击不同，这次的目标不是开发者的代码，而是 AI 助手本身。
什么是 TrapDoor 攻击？
TrapDoor 是一场同时针对 npm、PyPI 和 Crates.io 三大软件包仓库的协调供应链攻击。攻击者向流行开源项目提交 Pull Request，在项目中注入被精心构造的 CLAUDE.md 和 .cursorrules 配置文件。这两个文件本是 AI 助手的「工作指令」，AI 会将其当作可信指令执行——问题就出在这里。
当开发者克隆这样的仓库并使用 Claude Code 或 Cursor 时，AI 助手会自动读取并执行这些配置文件中的指令。攻击者利用了这一信任机制，在配置文件中植入恶意命令，AI 在「帮忙」的过程中悄悄完成窃取。
攻击规模与影响范围
- 涉及 34 个恶意软件包，384 个以上相关版本和构件
- 横跨 npm（JavaScript）、PyPI（Python）和 Crates.io（Rust）三大生态
- 主要目标群体：加密货币开发者、DeFi 开发者、AI 安全研究者
- 攻击者持续在各平台推送更新，活跃度极高
攻击者是如何操作的？
具体流程是这样的：第一步，攻击者找到热门开源项目，提交看似正常的 Pull Request，增加新功能或修复 bug。第二步，PR 中包含被篡改的 CLAUDE.md 或 .cursorrules 文件。第三步，开发者审核 PR 时只检查代码本身，往往忽略了 AI 配置文件。第四步，代码合入后，开发者下次使用 AI 助手时，恶意命令就自动执行了。
这不是传统的恶意代码注入，而是利用人类审核员的盲区——PR 的代码看起来完全正常，问题藏在 AI 会「读」但人类不一定「看」的地方。
为什么 AI 助手成了攻击面？
传统的供应链攻击直接污染代码库，等待开发者下载后自动中招。TrapDoor 的巧妙之处在于，它利用了 AI 助手的信任模型。Claude Code 和 Cursor 这类工具会读取项目根目录下的 CLAUDE.md、.cursorrules、.cursor/rules 等配置文件，这些文件的作用是告诉 AI 如何理解项目、遵循什么规则。AI 把它们当作「可信指令」，但人类往往不会逐一审查。
攻击链分析
| 阶段 | 操作 | 风险点 |
|---|---|---|
| 第一步 | 提交含恶意配置的 PR | 人类审核只看代码，不看 AI 配置 |
| 第二步 | PR 合入主分支 | 维护者信任贡献者身份 |
| 第三步 | 开发者克隆仓库 | 默认相信项目是安全的 |
| 第四步 | AI 助手执行恶意配置 | AI 视配置为可信指令 |
| 第五步 | 窃取钱包/密钥/凭证 | 静默完成，无告警 |
为什么以前没有这类攻击？
核心原因是 AI 编程助手的普及度。在 2023 年之前，很少有开发者会在日常工作中让 AI 执行配置文件里的指令。随着 Claude Code、Cursor、GitHub Copilot 等工具成为主流工作流，AI 开始「替人类执行任务」，攻击面才真正打开。
NVIDIA 近期发布的报告《From Assistant to Adversary》也指出，Cursor 这类工具会摄取外部贡献者提交的 PR 和 Issue 数据，而这些数据来源本质上不受信任——这正是 TrapDoor 攻击得以成立的技术根源。
哪些人最容易中招？
高危人群清单
| 人群 | 风险原因 | 潜在损失 |
|---|---|---|
| 加密货币开发者 | 直接操作钱包/DeFi 协议 | 代币被盗、钱包清空 |
| AI/机器学习工程师 | 频繁使用 Claude Code 等工具 | 云凭证泄露、模型被窃 |
| 安全研究人员 | 经常 clone 未知来源项目 | SSH 密钥被盗、身份伪造 |
| 独立开发者 | 缺乏安全审计流程 | 全线账户被攻破 |
真实案例：开发者如何被盗
案例一：加密货币交易员
某开发者在 GitHub 上发现一个看起来不错的开源套利工具，提交了 PR 并合入代码。几天后，他发现自己的 MetaMask 钱包被转空了——攻击者在他使用 Claude Code「分析合约」时，通过恶意配置拿到了钱包访问权限。丢失金额约 2.3 ETH。
案例二：AI 初创公司 CTO
一家 AI 初创公司的 CTO 从开源社区 fork 了一个 LangChain 增强项目，代码看起来质量很高。他让 Cursor 帮助快速审查整个代码库，Cursor 自动读取了项目中的 .cursorrules，其中包含将环境变量发送至外部服务器的指令。第二天，他发现 AWS 密钥已被滥用，账单爆增。
案例三：独立安全研究员
一名研究员在分析恶意软件样本时使用了 AI 助手辅助逆向。他从论坛下载了一个「优化版」的 IDA Pro 脚本插件，插件中夹带了恶意的 CLAUDE.md。AI 在执行指令过程中读取了他的 SSH 密钥，最终导致 GitHub 账号被攻击者用于恶意提交。
如何自查和防护？
立即检查清单
第一，检查项目中的 CLAUDE.md 和 .cursorrules 是否来自可信提交。如果你是项目维护者，对于任何包含 AI 配置文件修改的 PR，都要仔细审查内容。第二，使用 Socket 的免费工具扫描你的 package.json 或 requirements.txt，它可以检测已知恶意包。
第三，在 AI 助手中启用沙盒模式。Claude Code 支持通过环境变量限制文件访问，Cursor 也有只读模式选项。第四，隔离敏感操作。不要在有 AI 助手参与的环境中进行钱包操作或 SSH 密钥管理。
防护措施对比
| 措施 | 有效性 | 实施难度 | 推荐指数 |
|---|---|---|---|
| 审查 AI 配置文件 | ⭐⭐⭐⭐⭐ | 低 | 必做 |
| Socket 扫描依赖 | ⭐⭐⭐⭐ | 低 | 推荐 |
| AI 助手沙盒模式 | ⭐⭐⭐⭐ | 中 | 推荐 |
| 敏感操作隔离 | ⭐⭐⭐⭐⭐ | 中 | 强烈推荐 |
| 改用本地模型 | ⭐⭐⭐ | 高 | 可选 |
如果已经中招怎么办？
如果你怀疑自己的项目可能已被污染，立即执行以下操作：撤销所有近期生成的 API 密钥和 SSH 密钥；检查云控制台是否有异常访问记录；将干净环境中的代码重新克隆一份；检查 CLAUDE.md 等配置文件是否包含网络请求指令。
开源生态如何应对？
这次攻击也暴露了开源生态的深层问题。Pull Request 的审核流程是为人类设计的，AI 配置文件处于盲区。平台层面，GitHub 等平台可以考虑对包含 AI 配置文件修改的 PR 增加额外警告或审查机制。维护者层面，项目的 CLAUDE.md 和 .cursorrules 应该与代码一样纳入版本控制追踪。
对于整个行业来说，这是一个警示：AI 助手在工作流中扮演越来越重要的角色，但我们对 AI 安全模型的理解还远远不够。攻击者已经开始利用这一新前线，每一个开发者和安全团队都需要重新审视自己在 AI 时代的安全姿势。
总结
TrapDoor 供应链攻击的核心创新在于「攻击 AI 助手而非直接攻击人」。它利用了三个信任链的交汇点：平台对贡献者的信任、维护者对 PR 代码的信任、AI 助手对配置文件的信任。任何一个环节的松懈都会导致最终失守。
对于普通开发者来说，最务实的做法是：从今天起，像审查代码一样审查你项目中的 AI 配置文件。不要让攻击者利用 AI 的「听话」特性来绕过人类的安全直觉。
参考来源：Socket.dev 威胁情报、 NVIDIA 开发者博客、 Binance Square 安全分析、 ChainCatcher 报道
暂无评论内容