开源生态的安全攻防战正在进入一个新阶段。一场代号为TrapDoor的协调供应链攻击，同时针对了 npm、PyPI 和 Crates.io 三大主流包管理器，涉及 34 个恶意包。这场攻击的独特之处，在于它首次将 AI 编程助手——Claude Code 和 Cursor——作为攻击链条的支点。

攻击者的手法并非传统意义上的投毒或漏洞利用，而是进行了更高层级的“信任劫持”。他们向流行开源项目提交 Pull Request，在其中植入被操纵的 CLAUDE.md 和 .cursorrules 配置文件。当开发者克隆仓库并使用这些 AI 助手时，AI 智能体会将相应文件视为可信指令集并自动执行。这意味着，攻击者可以 绕过开发者的人眼审查，直接在 AI 将执行的“伪代码”层注入恶意逻辑。

这标志着 AI 辅助开发工具从“生产力工具”向“攻击面”的身份转变。以往的供应链攻击主要依赖恶意代码或隐蔽后门，开发者至少有机会通过代码审计发现异常。但在此次攻击中，恶意指令直接嵌入 AI 配置文件中，开发者可能永远不会主动审查这些文件，因为它们通常情况下只是指导 AI 行为风格或偏好的元数据。攻击者利用了这一盲区，让 AI 智能体成为事实上的“内鬼”——在无人察觉的情况下，执行窃取加密货币钱包、SSH 密钥和云凭证的命令。

从根源看，这场攻击映射出 AI 时代安全边界重构的紧迫性。传统安全模型强调对代码本身的信任，但 AI 开发工具对配置文件的无条件信任 打开了一个全新的攻击维度。开发者需要意识到：AI 助手并非智能到可以自动识别恶意指令。它们的“智能”来自开发者授予的权限与信任，而这种信任在恶意配置文件面前是脆弱的。

对使用 Claude Code 或 Cursor 的开发者而言，警惕已不再是可选项。建议立即检查项目中的 .cursorrules 和 CLAUDE.md 是否来自可信提交流，并考虑在执行 AI 助手生成的命令前增加人工确认环节。同时，开源项目维护者也应当对涉及 AI 配置文件的 Pull Request 加倍审查，因为这类攻击在代码审查模型内几乎是隐形的。

TrapDoor 攻击可能是 AI 供应链安全领域的一个分水岭。它揭示了：在 AI 助手日益流行的今天，我们不仅需要关注 AI 生成代码的安全性，更要关注 AI 自身“学习”和“执行”的规则是否被污染。当 AI 成为开发者的“第二大脑”，保护这个“大脑”的输入通道，将成为安全领域的新必修课。