一场代号为“TrapDoor”的供应链攻击正在三个主流包管理器（npm、PyPI和Crates.io）上同步进行。攻击者发布了34个恶意包，目标直指加密货币开发者、AI工程师和安全从业者——他们的钱包、SSH密钥和云凭证成为窃取对象。但真正让安全社区震惊的是攻击链的新维度：攻击者通过向流行开源项目提交看似无害的Pull Request，将经过精心操纵的CLAUDE.md和.cursorrules配置文件注入代码库。当其他开发者克隆这些仓库并使用Claude Code或Cursor等AI编程助手时，AI智能体会将这些文件当作可信指令执行——开发者可能完全不知情，便触发恶意命令。

这标志着AI助手首次被用作供应链攻击的跳板。此前，安全开发者只担心依赖包本身是否包含后门，而很少考虑AI工具读取的项目级配置文件是否可信。攻击者利用了AI助手普遍遵循的“项目配置优先”设计：Claude Code会读取仓库根目录下的CLAUDE.md作为行为指南，Cursor则依赖.cursorrules。这些文件本用于指定编码规范、工具调用规则，但攻击者可以在其中嵌入类似“执行某个curl命令下载恶意脚本”的指令。由于AI助手默认信任这些文件（尤其是当文件来自上游仓库的合法维护者提交时），攻击得以穿透开发者的心理防线。

与传统的依赖混淆或typofront攻击不同，TrapDoor攻击的隐蔽性极高。多数开发者不会对配置文件进行完整性校验，甚至不会注意到Pull Request中新增了一个看似文档的文件。一旦被感染的仓库被克隆，AI助手就会在第一次代码补全或对话时悄然执行恶意规则。攻击者还同步在多个生态系统中散布相同模式的恶意包，形成交叉感染的协同效应。目前安全公司Socket已公布详细的IoC（威胁指标）和攻击者基础设施信息，包括GitHub活动分析。

对于Claude Code和Cursor的用户而言，这意味着需要重新审视安全基线：来自不可信提交的配置文件和项目文档不应被AI助手自动信任。建议做法包括：审查每个Pull Request中新增或修改的CLAUDE.md/.cursorrules文件；在AI助手的设置中禁用对项目配置的自动应用；对AI助手执行的任何外部命令（如文件读取、网络请求）进行审计和批准。此外，也可以考虑使用hook脚本在AI助手初始化前扫描配置文件中的可疑模式（如curl、wget、base64解码等）。

从趋势角度看，TrapDoor预示着AI原生攻击面的兴起。随着编码助手的渗透率提升，针对其配置、提示注入和工具调用逻辑的攻击将激增。开发者不能仅停留在检查依赖包层面，将AI交互边界纳入威胁模型已是必须。如同过去十年供应链攻击从代码库蔓延到构建流水线，下一个十年可能蔓延到开发者桌面的AI代理。TrapDoor只是一个开始。