一场代号为TrapDoor的协调供应链攻击，同时攻陷npm、PyPI和Crates.io三大主流包管理器，涉及34个恶意包。这场攻击的独特之处，在于其首次将AI助手纳入攻击面——恶意代码不是通过传统软件漏洞传播，而是通过AI工具对项目配置文件的绝对信任，实现了对开发者机器的“借刀杀人”。

攻击者使用的战术异常精细。他们向热门开源项目提交看似无害的Pull Request，在代码中植入被篡改的CLAUDE.md和.cursorrules文件。当开发者克隆受感染的仓库后，使用Claude Code或Cursor等AI助手时，这些智能体会将这些配置文件当作权威指令执行。攻击者利用的是开发者对AI工具的无条件信赖——后者往往会不加校验地导入上下文文件并执行其中的命令。

目标群体高度明确：加密钱包、SSH密钥、云服务凭证和数据科学环境配置成为攻击者首要猎物。TrapDoor攻击套件内嵌了多个信息窃取模块，能够扫描并渗出包括私钥、AWS凭证、GitHub Token在内的敏感资产。Socket分析平台已经追踪到攻击者搭建的载荷交付和命令控制基础设施，技术栈和TTPs与常见的水坑攻击形成鲜明对比。

传统供应链攻击通常依赖代码执行或依赖混淆，而TrapDoor开辟了全新的路径——将AI智能体当作“第三方执行者”。开发者本无恶意，AI助手也非故意作恶，问题出在信任链条的断裂点：AI工具的设计逻辑是信任项目根目录下的配置文件为安全上下文，但攻击者正是利用这一点，通过合成虚假的上下文环境来诱导AI执行恶意操作。

对于使用Claude Code、Cursor等AI编码助手的开发团队，以下防御措施刻不容缓：

第一，对项目内的.cursorrules和CLAUDE.md等配置文件实施变更审查制度，任何改动必须经过代码评审；

第二，在AI助手的本地配置中设置白名单，只允许执行由项目负责人签字确认的配置文件指令；

第三，对工作流中的拉取请求进行自动化扫描，识别并隔离包含AI配置文件的提交；

第四，限制AI助手的网络访问权限，避免其直接调用系统级工具或访问密钥存储区。

TrapDoor暴露出的最深层问题，是AI开发工具安全设计的先天缺陷。当智能体对上游的“文档”和“配置”保持完全信任时，它们实际上会成为一条隐蔽的击穿防线。这一攻击手法预示着行业必须重新定义“信任边界”——对于AI助手而言，纯粹的文本输入应被视为不可信的来源。开发工具的未来版本需要引入配置文件的签名认证机制，或者最起码提供“仅执行来自已验证来源指令”的安全模式。