开发者或许习惯了警惕代码依赖中的恶意包，却少有留意AI助手“看到”的配置文件是否安全。一场名为“TrapDoor”的协调供应链攻击打破了这一认知盲区。攻击者同时向三大包管理器——npm、PyPI和Crates.io——投递了34个恶意包，并首次将AI助手的运行环境塑造成新型攻击面。

这次攻击的独特之处在于其多重渗透手法。除常规的包投毒外，攻击者向流行开源项目提交了精心伪装Pull Request，其中的关键载荷是两份被操纵的配置文件：CLAUDE.md和.cursorrules。这两类文件通常用于指导AI代码助手的代码风格、项目规范和自动执行动作。当开发者克隆被污染的仓库，并启动Claude Code或Cursor等AI辅助编程工具时，AI智能体便会自动读取这些文件，将其视为可信指令予以执行。其后果是，攻击者可在开发者毫无察觉的情况下，远程运行恶意命令。

这种攻击模式与传统供应链攻击最大的区别在于，它绕开了代码审查和依赖扫描。通常，安全团队会关注开源包中的可疑函数、哈希校验或网络请求。但在TrapDoor攻击中，恶意逻辑藏身于AI工具的行为配置文件。这类文件在技术审查中往往被当作“元数据”或“文档”忽视，不存在直接可执行的代码，却因AI工具的结构化解析而获得实际执行力。这类似于一种“信任转嫁”攻击：开发者信任AI工具，AI工具信任配置文件，而攻击者正是利用了这层信任链的最顶端。

从攻击目标来看，恶意包明确针对加密货币开发者、AI从业者以及安全研究人员，意图窃取的数字资产包括：钱包密钥、SSH私有密钥以及云服务凭证。这一精准选择表明，攻击者清楚开发环境中存储着高价值的凭证，且这些凭证在AI辅助代码操作过程中容易被暴露。

对于使用Claude Code和Cursor的开发者，当下最务实的防御措施是：立即检查项目仓库中.cursorrules和CLAUDE.md文件的提交记录，确认其来源是否可信。如果这些文件来自未知或最近被强制合并的Pull Request，应视作潜在风险。此外，建议在AI工具配置中限制自动执行命令的范围，避免AI模型在未经二次确认的情况下执行系统级操作。更长远来看，AI辅助编程工具的信任模型需要重构——不能自动将配置文件中的指令等同于用户的显式意图。

TrapDoor攻击的出现，标志着AI工具从“辅助生产力工具”演变为“攻击者利用的侧信道”。未来，针对AI配置文件的供应链注入可能成为常态。开发者社区和工具维护方需尽快制定防御规范，包括对配置文件进行SAST扫描、强制签名验证以及建立AI指令的白名单机制。否则，下一个看似无害的.md文件，就可能成为入侵开发者机器的后门。