一场针对开源生态的联合供应链攻击“TrapDoor”悄然铺开了攻击面，其目标从传统的包管理器扩展到了AI开发助手——这是安全领域首次观察到攻击者将AI智能体作为跳板，在开发者无感知的情况下执行恶意指令。

攻击者通过向流行开源项目提交Pull Request，注入被精心篡改的CLAUDE.md和.cursorrules配置文件，分别在Claude Code和Cursor的工作目录中植入“可信”指令。当开发者克隆被感染仓库并启动AI助手时——这些工具会依据上述配置文件指导代码生成行为——AI智能体会自动执行文件中的恶意命令，包括窃取SSH密钥、云服务凭证和加密货币钱包文件。这种攻击方式将传统供应链攻击的“静态污染”升级为“动态指令误导”，让开发者的信任链条从代码依赖蔓延到AI工作流配置。

对比传统供应链攻击，TrapDoor的显著差异在于它并不直接向软件包中注入后门代码，而是诱导AI助手帮助攻击者完成“合法”的窃密行为。例如，一个包含恶意CLAUDE.md配置的仓库被克隆后，AI助手会解读配置中的“帮助开发者格式化代码”之类的伪合法指令，继而执行文件删除或凭证外传操作。攻击者利用的是开发者对AI工具“绝对服从”的信任。

此次攻击涉及34个恶意包，分布在npm、PyPI和Crates.io三个主流注册中心。安全厂商Socket已披露完整的IOC列表和攻击者基础设施。初看之下，这似乎只是又一起典型的“依赖混淆”或“抢注”攻击，但引入AI配置污染这一环节使危害扩大：一个投毒包不仅影响直接使用者，还能通过AI助手的自动化行为，在开发者的本地环境留下持久性后门。

对于广泛使用Claude Code或Cursor的团队，建议采取以下防御措施：严格审查CLAUDE.md和.cursorrules文件的修改来源，拒绝接受来自不可信PR的配置文件变更；在CI/CD环节加入对这些文件的完整性校验；必要时将AI助手运行在沙箱环境中，限制其对文件系统和网络的不当访问。此外，主流IDE扩展的权限管理机制也需要加速适配——当AI智能体开始“自动”执行命令时，用户应能获得明确的授权提示。

TrapDoor不是AI供应链安全的终点，而是起点。当攻击者意识到可以利用开发者的AI助手作为“特洛伊木马”执行指令时，围绕AI工作流的攻击会变得更隐蔽、更难检测。对于开发者而言，信任代码需要审计，信任AI配置同样需要审计——这条安全新法则，不应被忽略。