一场代号TrapDoor的协调供应链攻击正在改写软件供应链安全的历史：它首次将矛头指向了AI助手。攻击者向npm、PyPI和Crates.io三大包管理器投放了34个恶意包，同时向流行开源项目提交Pull Request，篡改其中的CLAUDE.md和.cursorrules文件。这些文件原本用于指导AI编码助手（如Claude Code和Cursor）的行为，一旦被注入恶意指令，AI智能体便会在开发者毫不知情的情况下执行数据窃取和凭证盗取操作。

与传统的依赖混淆或typosquatting攻击不同，TrapDoor的核心创新在于将AI智能体的信任链作为突破口。CLAUDE.md和.cursorrules是专为AI助手设计的配置文件，它们描述了项目结构、编码规范甚至自动化任务。当开发者克隆被污染的仓库并启动AI助手时，模型会自动读取并信任这些文件，仿佛它们是人类开发者间的约定。攻击者利用这一信任缺口，在配置文件中嵌入形如“运行此命令以初始化项目”的指令，实际弹出恶意负载——窃取加密货币钱包、SSH密钥、AWS/GCP凭证等敏感资产。

从攻击链看，TrapDoor展现了高度协调性：同时攻击三大包管理器，意味着攻击者对上游生态有深入理解；提交PR到活跃开源项目，减少了人类审核者对“额外配置文件”的警惕；而针对性窃取AI和安全开发者的凭证，则表明攻击者瞄准了高价值目标。根据安全团队Socket的分析，这些包及其背后的基础设施（包括攻击者托管的payload配置服务器）已经暴露了大量IoC指标。

对比过去三年发生的SolarWinds、CodeCov等供应链攻击，TrapDoor的独特之处在于扩大了“可被攻击的信任面”。传统供应链攻击依赖依赖关系或构建脚本，而TrapDoor利用的是AI助手与配置文件之间的隐性信任——开发者通常不会像审查代码那样审查配置文件，AI助手也缺乏对配置文件的完整性校验。这本质上是对AI生产力工具安全盲区的精准打击。

对于使用Claude Code或Cursor的开发者，保护措施应立即启动：严格审查仓库中的.cursorrules和CLAUDE.md文件来源，只接受来自可信提交的版本；在AI助手的配置中禁用自动执行命令或增加确认环节；使用安全扫描工具（如Socket）监测项目中的可疑配置指令。更长远看，AI工具厂商需考虑为配置文件添加数字签名或内容完整性校验，开发者社区也应建立配置文件安全规范——这不是一场可以忽视的“小规模试验”，而是AI时代的供应链安全首场实战。