一场代号“TrapDoor”的精准供应链攻击，正在颠覆开发者对AI编码助手的信任。安全研究机构Socket披露，这场攻击同时污染了npm、PyPI与Crates.io三大包生态系统，投放了共计34个恶意软件包。更危险的是，攻击者通过向流行开源项目提交恶意的Pull Request（PR），悄悄注入了篡改过的 CLAUDE.md 与 .cursorrules 配置文件。当毫无防备的开发者克隆这些“毒仓库”并使用Claude Code、Cursor等AI助手时，工具会自动将这些配置文件视为可信指令，从而可能在开发者毫无知觉的情况下执行任意命令。

这是首次将AI编码助手作为供应链攻击的跳板。此前，供应链攻击多集中于在代码中埋设后门或窃取环境变量；而TrapDoor的攻击逻辑则更加隐蔽——它利用了开发者对AI助手的“信任盲区”。配置文件中往往定义了项目结构、编码规范甚至是自动化脚本，AI智能体会将其视为“官方指南”并严格遵循。攻击者正是利用这一点，在配置文件中植入了窃取加密货币钱包、SSH私钥及云服务凭证的有效载荷，目标直指面向AI与区块链领域的高价值开发者群体。

从实际影响来看，这类攻击借助开源项目的天然“信任链”进行传播。开发者不会逐一审查PR中那些看似无害的配置文件修改，而AI助手又没有能力区分“合法指令”与“恶意诱导”。一旦CLAUDE.md或.cursorrules中包含隐式的curl、wget或Python脚本执行指令，AI代理便会代劳。这种“指令注入”手法，本质上与Web应用程序中的提示注入攻击同源，却被移植到了开发流程的“上游”。

根据Socket提供的完整IOC（入侵指标）列表，攻击者搭建了位于多个IP地址上的远程载荷及配置服务器，一旦AI助手触发执行，即可回传目标设备中的敏感文件。这标志着攻击者正在逆向利用AI最引以为傲的“理解上下文”能力——他们不再试图绕过AI的安全护栏，而是直接使其成为攻击链中尽职尽责的执行环节。对于已经深度依赖AI编写代码的团队，这意味着安全审计的边界需要从“代码仓库”进一步延伸至“AI的行为配置文件”。

给开发者和工程团队的实用建议：立即检查项目中的 .cursorrules 和 CLAUDE.md 是否来自你亲自审查过的可信提交。在拉取开源仓库的PR时，不应只审查代码差异，更应着重关注这些指导AI行为的元数据。对于使用Claude Code或Cursor的团队，建议配置安全监控脚本，自动预警或隔离来自网络请求的执行行为。未来的SDLC（软件开发生命周期）中，CI/CD流水线不仅应检查代码来源，还需纳入“AI配置文件审计”这一环节——因为攻击者已经证明，他们比我们更早懂得了如何向AI“写信”。