一场代号“TrapDoor”的协调供应链攻击同时向npm、PyPI和Crates.io三大包管理器投放了34个恶意包，目标直指加密货币、AI及安全开发者的钱包、SSH密钥和云凭证。然而该事件更值得警惕的并非传统依赖投毒手法，而是其利用AI助手配置文件的信任机制作为攻击跳板——这是安全社区首次观察到此类攻击面。

攻击者向多个流行开源项目提交了精心构造的Pull Request，这些PR的核心变动是向仓库中添加被篡改的CLAUDE.md和.cursorrules配置文件。这两个文件分别被Claude Code和Cursor这类AI编码助手视为“可信指令源”。当开发者克隆了被感染的仓库并启动AI助手后，智能体会自动读取这些文件中的恶意指令，并在开发者毫不知情的情况下执行系统级命令——例如解密存储在本地环境变量中的云凭证、窃取SSH密钥或向远程攻击控制服务器发送敏感数据。

与传统供应链攻击（如依赖混淆、恶意包替换）相比，TrapDoor的隐蔽性大幅提升：恶意代码并非嵌入开源库的运行时逻辑，而是伪装成AI助手的“行为规范”。由于许多开发者默认信任AI助手对项目配置文件的读取权限，且Pull Request本身来自合法项目，这类攻击极难在代码审查阶段被发现。更关键的是，一旦AI助手执行了恶意指令，它可能通过自动完成、代码生成等功能将后门植入开发者的最终产品，形成二次传播。

截至目前，安全团队已披露所有恶意包的哈希值、GitHub攻击者账户及相关基础设施IP。初步分析显示，攻击者可能利用了某些流行的自动化工具（如Dependabot或Renovate）的缺乏权限校验的流程，以批量方式提交大量含毒PR。虽然这三个平台已下架恶意包，但已克隆受感染仓库的开发者依然面临风险——攻击者设置的配置文件可能已被合并到本地项目“预设规则”中，并在后续每次启用AI助手时自动生效。

对于使用Claude Code、Cursor或其他类似AI编码助手的开发者，应立即检查项目根目录下的.cursorrules和CLAUDE.md文件来源，确认其是否来自可信的提交者。更通用的防护措施包括：在CI/CD流程中添加对AI配置文件变更的自动审计、禁止AI助手从外部仓库自动加载规则、对SSH密钥及云凭证实施最小权限策略。从行业趋势来看，随着AI助手逐渐成为开发流程的核心组件，其配置文件及插件体系将成为供应链攻击的下一个重点突破方向。工具厂商应优先考虑在规则执行前增加签名验证或手动确认环节，避免信任链被单点突破。