一场代号TrapDoor的供应链攻击正以全新的方式撕开软件开发的安全缺口。它不再停留于传统手段——嵌入依赖包、篡改构建脚本或伪装更新提示，而是将目标对准了正在迅速普及的AI编程助手，比如 Claude Code 和 Cursor。攻击的核心机制简单却令人不安：当开发者克隆一个被注入恶意指令的仓库，并使用智能助手分析或重构代码时，AI 智能体将忠实地执行隐藏在 CLAUDE.md 或 .cursorrules 配置文件中的恶意命令，在开发者毫无察觉的情况下，窃取密钥、钱包与凭证。

此次TrapDoor攻击同时蔓延至npm、PyPI 和 Crates.io三大主流的包管理器，共计投放34个恶意包。攻击者并未采用系统级漏洞，而是瞄准了AI智能体的配置信任链。他们向GitHub上的热门开源项目提交恶意的Pull Request，注入被篡改的配置文件。这些文件本身并非二进制恶意代码，而是看似无害的配置指令，引导AI助手执行特定的操作——比如下载远程载荷、替换环境变量或读取本地敏感文件。

在传统供应链攻击中，开发者通常依靠包签名、依赖审计或SBoM（软件物料清单）来防御。然而，AI助手的自动化执行机制模糊了“配置指令”与“恶意命令”的边界。当AI智能体将.CLAUDE.md视为权威规则，并自动为其赋予高权限，开发者就失去了每一步操作的可见性。这不仅扩大了攻击面，更暴露了一个根本问题：我们是否默认信任了AI助手中的每一行配置？

针对此事件，安全公司Socket发布了详细的技术分析报告，包括恶意包的清单、IoC（入侵指标）以及攻击者背后的基础设施与GitHub活动轨迹。对于依赖Claude Code、Cursor等AI编程工具的开发者团队，最迫切的行动是立即审查项目中.cursorrules和CLAUDE.md文件的来源，确保它们来自可信的提交，并配置敏感提示词的白名单机制。

从行业趋势来看，TrapDoor攻击并非孤例。随着AI智能体逐步接管“编码→审查→部署”的完整流程，攻击者必然会将投毒目标从二进制文件转向这些隐形的“指令层”。未来，为AI助手设定最小权限原则、在智能体执行危险操作前引入二次确认机制，以及建立针对AI配置文件的供应链审计标准，将成为软件安全的新必修课。

开发者不应因噎废食，但必须在享受AI编程效率的同时，重新审视自身对“第三方指令”的默认信任。在AI智能体成为新“入口”的今天，每一次代码补全，都可能是一次安全测试。