一场名为TrapDoor的供应链攻击正在悄然蔓延，它的战术设计显示了一个可怕的趋势：攻击者不再仅仅瞄准代码或包，而是瞄准开发者对AI助手的信任。这场攻击同时渗透了npm、PyPI和Crates.io三大核心包管理器，投放了34个恶意包，目标直指加密货币开发者、AI从业者以及安全工程师的敏感资产——加密货币钱包、SSH密钥和云服务凭证。

与传统供应链攻击不同，TrapDoor展现了一种极其精妙的攻击手法：攻击者向流行的开源项目提交Pull Request，将经过精心构造的.cursorrules和CLAUDE.md配置文件植入项目中。当开发者克隆这些仓库，并使用Cursor或Claude Code等AI辅助编程工具时，AI智能体会自动将文件中的内容视为可信的执行指令。表面上是配置文件，实际上是递交给AI助手的恶意命令——它可能在开发者毫无察觉的情况下，代表用户执行危险的Shell命令，窃取凭证或回传数据。

这一攻击模式的创新之处在于，它利用了AI助手运作的核心信任模型。传统的供应链攻击依赖开发者手动执行恶意代码，或是依赖构建管道中的自动化流程。而TrapDoor则是将AI助手转化为攻击的“前线执行者”：攻击者不需要攻破构建服务器，也不需要等待开发者手动验证，只需以合法修改的外观，将指令放在AI工具默认读取的位置即可。这是人类开发者无法通过常规代码审查发现的隐蔽方式。

横向对比以往的依赖混淆攻击、恶意包植入攻击（如dependency confusion和typosquatting），TrapDoor的威胁级别更高，因为它打开了AI智能体作为攻击面的全新攻击向量。在AI辅助开发逐渐从实验走向生产环境的当下，这类攻击可能迅速演变为通用方法，并催生更多专门针对AI工作流的恶意攻击。

对开发者而言，这是一个明确的信号：

第一，检查项目中的CLAUDE.md和.cursorrules是否来自可信贡献者，特别是来自未审阅的Pull Request。第二，在使用AI辅助工具时，避免授予其无限制的系统命令执行权限。第三，保持对安全审计工具的更新，例如Socket等新一代供应链安全平台已开始纳入此类威胁模型。第四，强化个人凭证管理，将加密密钥和云凭证分离存储，并限制AI助手的访问范围。

在AI智能体进入开发者工具链的第一个成熟周期，TrapDoor的攻击已经暴露了信任机制的短板。未来，安全防御的焦点，可能要从代码本身，转移到AI助手如何解读代码环境的指令。开发者、平台方和安全社区需要共同思考：如何定义和验证AI助手环境下的“可信配置文件”？这可能是整个行业即将面临的持久课题。