一场代号为“TrapDoor”的供应链攻击正在颠覆安全从业者对“代码信任”的认知。不同于传统的依赖劫持或typosquatting，此次攻击首次将AI编码助手的隐性信任机制作为突破点——通过污染开源项目中的AI配置文件（CLAUDE.md和.cursorrules），攻击者让开发者最依赖的“智能代码伙伴”沦为内鬼。

攻击手法分为三层。第一层：在npm、PyPI、Crates.io三大包管理器同步发布34个恶意包，覆盖常见的typosquatting变体（如“web3-utils”的拼写替换），用于窃取浏览器钱包、SSH密钥和云服务凭证。第二层：精心构造的GitHub Pull Request——这些PR看似在修复文档或添加功能，实则向项目的根目录插入被篡改的AI配置文件。例如，恶意.cursorrules中可能包含“eval用户输入的加密货币地址”或“读取~/.ssh/id_rsa并上传”的指令。

真正的颠覆在第三层：当开发者使用Claude Code、Cursor等AI助手时，这些工具会默认将项目中的配置文件视为权威指令集。AI智能体会忠实地执行文件中定义的“规则”，包括启动子进程、修改环境变量、甚至通过网络外发数据。关键在于，大多数开发者从未想过要审查.cursorrules——它们就像项目中的“魔法注释”，被AI当作第一优先级的行为准则，而人类肉眼几乎不会发现其中暗藏的恶意逻辑。

从目标选择看，攻击者显然做了精准画像：加密货币开发者常持有钱包私钥；AI/安全开发者往往拥有高权限SSH密钥和云访问令牌。而AI编码助手恰恰在这些群体中渗透率极高。这与传统的供应链攻击（如通过恶意npm包注入后门）相比，攻击面从“代码依赖”扩展到了“代码元数据”和AI的信任链，使得防御更加困难。

对开发者而言，这不再是“不要安装不明包”的旧劝诫。现在必须建立新的安全习惯：严格审计所有AI配置文件（.cursorrules、CLAUDE.md、.clinerules等），将其纳入代码审查范围；在AI助手中禁用“自动信任项目规则”开关，或设置额外的执行确认步骤；对高危操作（如文件读取、网络请求）启用沙箱限制。同时，平台方（如GitHub、包管理器）应增加对AI配置文件变更的敏感度，在PR中标记此类文件的修改为高风险事件。

更大的趋势是：随着AI助手从“补全代码”向“自主执行”演进——Cursor正在测试Agent模式，Claude Code支持系统命令调用——供应链攻击的下一个主流形态很可能就是“AI配置劫持”。开发者辛苦构建的智能工作流，一旦被恶意配置污染，就会变成攻击者的自动化武器。TrapDoor只是第一枪。