一场代号为“TrapDoor”的协调供应链攻击，正在颠覆开源安全领域的既有认知。攻击者首次将AI代码助手——包括Claude Code和Cursor——作为攻击面，通过操纵开发者信任的AI配置文件，实现隐蔽的恶意命令执行。这是安全行业有史以来首次记录到针对AI智能体工作流的系统性攻击。

本次攻击覆盖了npm、PyPI和Crates.io三大主流包管理器，共发现34个恶意包。攻击目标高度精准：加密货币开发者、AI工程师和安全研究人员持有的钱包文件、SSH密钥和云服务凭证。攻击者通过向流行的开源项目提交Pull Request，注入被精心篡改的CLAUDE.md和.cursorrules配置文件。

攻击的核心机制在于：当开发者克隆包含这些恶意配置的仓库，并启动Claude Code或Cursor等AI助手时，智能体会将这些文件视为可信指令集加以执行。这并非传统的代码注入或者软件依赖劫持，而是一种更恶劣的“信任链污染”——攻击者并不直接修改执行代码，而是操纵AI助手对开发者行为的理解。开发者可能在毫不知情的情况下，被AI助手引导执行恶意命令，泄露敏感信息。

与过去依赖后端服务器、编译环节或软件提权的供应链攻击不同，“TrapDoor”利用了AI智能体特有的“规则引擎信任模型”。在传统的开发流程中，配置文件通常只影响编辑器外观或lint规则，而非实际执行来源。但AI助手的工作流将配置文件提升到了“可编程指令集”的地位，赋予了它们隐式的执行权限。这一转变尚未被大多数开发者及安全团队充分认知。

Socket安全研究人员提供了详尽的技术分析，包括恶意包列表、可展开的IOCs以及攻击者托管的后端基础设施。值得注意的是，所有恶意包和Payload基础设施均在攻击被发现后迅速下线，但其中部分代码仍可通过缓存或其他镜像访问。

对于使用Claude Code、Cursor或任何依赖.cursorrules及CLAUDE.md作为行为指导的AI助手的开发者，立即采取防御措施至关重要：

• 对代码仓库中的所有配置文件实施严格审查，特别是来自非受信提交者的Pull Request。
• 为AI助手启用手动确认模式，避免自动执行任何可能修改文件或网络的指令。
• 在团队中建立“AI配置文件审计”流程，将其纳入代码审查的硬性环节。

“TrapDoor”攻击反映了AI工具化带来的新安全挑战：当开发者信任AI的“建议”时，也无形中为攻击者打开了一扇后门。未来，对AI工作流的运行时监控和漏洞供应链管理，将成为每个技术团队必须正视的安全议题。