开源生态信任模型已被打破，但这次攻击瞄准的不再是简单的包提权或依赖混淆。

一场针对AI编码助手的新型供应链攻击“TrapDoor”在三大主流包注册中心（npm、PyPI、Crates.io）同步展开，共部署34个恶意包。攻击的目标资产包括加密货币钱包、SSH密钥和云服务凭证，但其攻击路径展现出前所未有的精巧设计：攻击者并未通过传统方式入侵包维护者账户或投毒源码，而是利用AI编码助手对项目配置文件（CLAUDE.md和.cursorrules）的“信任”机制，将AI助手变为恶意代码的传播终端。

这是业界首次将AI助手作为攻击面的实战案例。核心攻击链如下：攻击者以优化贡献为名，向流行开源仓库提交Pull Request，在PR中附带被篡改的CLAUDE.md或.cursorrules文件。这些配置文件针对Claude Code、Cursor等支持项目级配置的AI编码助手进行了精确适配。当毫不知情的开发者克隆或同步该仓库并启动AI助手时，助手会自动读取这些配置文件，将其中的指令当作可信任的执行脚本处理。攻击载荷通过隐藏的shell命令、条件执行钩子或类定义覆盖实现。

攻击理论上是“零点击”触发，因为AI助手的自动化特性使其无需开发者手动运行文件，配置文件被视为项目默认行为的一部分。这极大地降低了攻击的感知成本：开发者可能仅执行一次仓库同步，AI助手便在后台完成恶意命令的投递与执行。

从技术架构看，这场攻击将AI工具的“辅助信任”转化为安全弱点。传统供应链攻击依赖于软件包管理器的权限提升或依赖混淆，而TrapDoor攻击利用的正是AI编码工具对“项目内配置”的高权限执行机制。当前，Claude Code默认读取项目根目录的CLAUDE.md，Cursor则依赖`.cursorrules`来调整代码补全与自动操作行为。攻击者正是钻了这两个工具缺乏隔离沙箱的漏洞。

对于日常依赖AI助手的开发者，建议立即采取以下防护措施：

• 审查所有CLAUDE.md和.cursorrules文件的提交记录，确保未包含来自非核心维护者的PR内容；
• 在CI/CD流水线中增加配置文件变更告警规则，尤其是那些修改AI助理行为模式的提交；
• 考虑为AI编码助手配置“只读”模式或开启明确的执行权限确认弹窗，阻止无提示的后台执行；
• 使用Socket、Snyk等恶意包扫描工具，对项目依赖树及配置进行完整性校验。

这项攻击还暴露了更深层的行业结构问题：开源项目的贡献与审核流程尚未适配AI协作工具的普及。一个看似无害的配置文件PR，可能因为AI代理的自动执行机制而变成后门。未来供应链攻击的潜在向量将从“代码层面”扩展到“指令层面”——配置文件、环境变量、AI行为规则都可能是未被覆盖的边界。

正如安全研究员Kim Monismus所述，TrapDoor攻击不是孤立的恶意软件传播事件，而是一次精心策划的、针对AI生态的降维打击。对于依赖AI编码助手的开发者和团队，应急响应预案需要将AI自身的行为作为监控对象，同时重新定义开源团队内部的配置文件变更权限等级——“信任”红线，必须随AI工具的部署而重新划定。