一场名为“TrapDoor”的协调供应链攻击，已同步席卷三大主流包管理器——npm、PyPI与Crates.io。它的特别之处不在于投递了34个恶意包，而在于首次将AI编码助手纳入攻击面，形成了一条从开源仓库到开发者终端的全新感染路径。

攻击者选择了一个微妙的切入点：AI助手的“置信机制”。 在通常的工作流中，Claude Code依赖项目根目录的CLAUDE.md文件获取上下文与指令，Cursor用户则习惯通过.cursorrules配置文件设定AI行为。这两个文件默认被AI智能体视为“可信指令”。攻击者正是利用了这一点：向流行开源项目提交伪装为代码修复或功能升级的Pull Request，注入被精心修改的AI配置文件。当开发者克隆或同步这些仓库，并用AI助手打开项目时，智能体会将这些文件当作团队约定予以执行，从而在开发者完全无感知的情况下运行恶意命令。

这种攻击范式的创新性在于：它绕过了传统供应链攻击依赖的“代码执行”环节。过去，恶意包通常需要在安装或运行时触发payload，容易被沙箱或静态分析检测。而TrapDoor的载荷并不在代码中，而是在AI解释的指令中。开发者即便不运行任何可疑脚本，仅凭“打开项目”这一动作，就足以让恶意指令生效。

从行业背景来看，这一事件标志着AI智能体时代的供应链安全边界正在重构。当前，几乎主流的AI编码助手的规则文件均缺乏签名验证或来源审计机制。此前行业对AI安全的关注多集中在数据隐私和模型偏见上，对“智能体被用作信任链攻击节点”的风险认知严重不足。结合Socket披露的IOC与GitHub活动记录，攻击者已搭建了配套的C2基础设施，表明这不是概念验证，而是一次有组织、有目标的定向渗透。

对于Claude Code与Cursor的用户，立即检查项目中是否包含来自非可信提交者的CLAUDE.md或.cursorrules文件，是当下优先级第一的安全动作。 更长期的策略包括：在Git工作流中增加对AI配置文件的审核门槛，要求此类文件必须由项目维护者签名；在CI/CD流水线中加入对配置文件内容的恶意指令扫描；以及锁定AI工具的版本，避免自动获取最新但未经验证的项目配置。

TrapDoor攻击预示着一个新的攻防维度：AI不再是单纯的生产力工具，它正在成为攻击者眼中的“信任跳板”。当开发者把决策权部分交给智能体时，攻击者便可以绕过人的防线，直接操纵机器。这个攻防博弈，才刚刚开始。