一场代号“TrapDoor”的供应链攻击正在技术圈引起震荡。与以往依赖恶意包或依赖混淆的传统手法不同，本次攻击首次将AI编码助手——Claude Code和Cursor——作为执行层，将攻击面从代码仓库延伸到开发者本地的智能体环境。攻击者通过向流行开源项目提交伪造的Pull Request，植入被篡改的CLAUDE.md和.cursorrules配置文件。当开发者克隆项目并在AI助手中打开时，这些文件被当作可信指令直接执行，AI智能体可能在用户无感知的情况下运行窃取脚本。

具体而言，TrapDoor共释放34个恶意包，覆盖Node.js（npm）、Python（PyPI）和Rust（Crates.io）三大生态。这些包伪装成常规依赖，但核心载荷是盗取加密货币钱包文件、SSH私钥以及AWS/GCP等云服务凭证。攻击的突破点在于：传统供应链攻击多依赖代码执行或依赖树污染，而TrapDoor利用了AI助手对项目级配置文件的绝对信任机制。例如，Cursor在启动时会读取.cursorrules，Claude Code则规范CLAUDE.md中的指令——攻击者正是利用这一自动化流程，将恶意命令隐藏在看似无害的AI配置中。

横向对比来看，过去几年中，恶意包投毒（如PyPI上的Colourama事件）和依赖混淆（如uAPK）主要是通过代码库自身漏洞实现攻击，而TrapDoor首次将“智能体执行策略”作为攻击面。这意味着开发者即使是拉取安全代码库，只要其中包含了被污染的AI配置文件，本地AI助手就会扮演“恶意代理”的角色，自主完成数据外泄。这种攻击更难被传统SAST工具或代码审计发现，因为配置文件本身不包含可执行代码，而是通过AI解释器触发系统调用。

对于Claude Code和Cursor用户，首要防范措施是检查仓库中CLAUDE.md和.cursorrules的提交来源。任何来自非项目维护者、且历史记录异常（如短时间内新增大量修改）的配置变更都应视为可疑。此外，建议在开发容器或沙盒中限制AI助手的文件系统访问权限，避免其直接操作密钥目录。安全团队应加入对AI配置文件的CI/CD扫描规则，监控此类文件的异常变更。

TrapDoor事件揭示了一个必然趋势：随着AI辅助编码工具嵌入开发流程，攻击者将从攻击代码本身转向攻击“代码的理解者”。未来，对抗重心将从包管理器安全扩展到智能体运行时安全。开发者与安全厂商需要重新定义信任边界：AI助手不再仅仅是工具，它正成为供应链中最脆弱的代理节点。