TrapDoor 供应链攻击：npm、PyPI 与 Crates.io 遭大规模入侵，AI 编码助手沦为窃密工具

一场名为 TrapDoor 的大规模供应链攻击正在威胁全球开发者，它通过 npm、PyPI 和 Crates.io 三大主流代码仓库，将凭据窃取恶意软件植入到伪装成正常开发工具的软件包中。安全公司 Socket 的研究人员最早发现了这次攻击，目前已确认 至少 34 个恶意包、超过 384 个版本 参与其中，最早的活动记录可追溯到 2026 年 5 月 22 日 UTC 时间 20:20 。

这场攻击并不是漫无目的地撒网，它目标明确——加密货币、去中心化金融（DeFi）、Solana、Sui 以及 AI 领域的开发者成了主要猎物 。攻击者很清楚，这些开发者手里往往掌握着钱包私钥、云基础设施权限和关键代码库的访问令牌，一旦攻破一台工作电脑，就等于打开了通往巨额资产和核心运维体系的大门 。

更令人警惕的是，TrapDoor 使用了一种前所未见的逃逸技术：利用零宽 Unicode 字符，把恶意指令藏进 .cursorrules 和 CLAUDE.md 这类 AI 编码助手的配置文件里。这些字符在普通文本编辑器中完全隐形，人类开发者和常规代码审查根本看不出任何问题，但 Cursor、Claude Code 等 AI 工具在读取文件时，却能“看到”并执行这些隐藏命令，从而在“例行安全扫描”的伪装下，悄悄完成信息收集和外泄 。

横跨三大生态的攻击手法

TrapDoor 攻击团伙同时对 npm、PyPI 和 Crates.io 发起渗透，并根据每个仓库的技术特点，量身定制了不同的恶意行为触发方式 。

npm（21 个恶意包）

这次攻击中，npm 是重灾区。恶意包利用 postinstall 钩子，在包安装后自动执行一个名为 trap-core.js 的核心载荷——该脚本长达约 1,149 行，能系统性地扫描受害者的开发环境，寻找各类凭据并外传 。

PyPI（7 个恶意包）

Python 生态中的恶意包手法更隐蔽，它们在包被导入时（import time）会从远程服务器拉取并执行一段 JavaScript 载荷，从而实现与 npm 版本相同的凭据窃取逻辑 。

Crates.io（6 个恶意包）

针对 Rust 开发者，攻击者选择在 build.rs 构建脚本中动手脚。这意味着，哪怕恶意包的核心功能还没有真正被调用，构建过程一旦启动，窃密代码就已经开始运行 。

这些恶意包都把自己包装成对开发效率“有帮助”的工具，比如 token-usage-tracker（令牌使用追踪器）、prompt-engineering-toolkit（提示工程工具包）、eth-wallet-security-auditor（以太坊钱包安全审计器）等，名字听起来相当专业，很容易让目标社区的程序员放松警惕 。

究竟哪些凭据正在被盗

TrapDoor 的窃密载荷像是一台不知疲倦的扫描仪，在受害机器上搜寻各种高价值“钥匙”。根据 Socket 团队的逆向分析，以下凭据类型是他们的重点目标 ：

• 加密货币钱包文件与密钥库（Keystore）
• SSH 私钥
• GitHub Personal Access Token（个人访问令牌）
• AWS 云服务凭证
• 环境变量中的 API 密钥
• 浏览器储存的账号密码与钱包扩展数据
• 其他各类开发者机密信息

在多份公开报告中，MetaMask 和 Phantom 这两个主流浏览器钱包扩展被明确点名 。GitHub 令牌的失窃尤其危险，攻击者不仅能访问私有代码库，更可能向 CI/CD 流水线植入恶意代码，或以受害开发者的身份横向渗透，进入更多系统 。

谁是被针对的目标

Socket 的调查确认，攻击方的主要目标是 加密货币、DeFi、Solana、Sui 以及 AI 领域的开发者 。恶意包的命名策略几乎是为这些社区量身定做的，主题高度集中在钱包安全审计、交易监控、智能合约开发以及 AI 上下文工具等方面。

攻击者之所以如此精准地“投放”，是因为他们明白，这些生态里的开发者不仅拥有实际控制着大额资产的私钥，还能接触云基础设施并持有开发工具链上的各种高权限——一台工作站的沦陷，通常就意味着财务损失和运营灾难的双重打击 。

把 AI 助手变成“内鬼”：零宽 Unicode 攻击的致命一击

TrapDoor 最令人拍案的技术创新，在于它直接挑战了开发者与 AI 编码助手之间的信任边界。恶意包会尝试在项目中修改或植入 .cursorrules 和 CLAUDE.md 文件——这两个配置文件正是开发者用来向 Cursor、Claude Code 等 AI 编程工具“交代”项目专属规则的地方 。

攻击者在这里动了手脚：他们在文件中嵌入使用零宽 Unicode 字符（比如 U+200B、U+200C、U+FEFF）编写的隐藏指令。在 VS Code 或者 Vim 这类编辑器里，这些字符不会显示任何痕迹，肉眼和常规代码 diff 完全看不出任何异常 。

然而，AI 编码助手在解析文件时，会完整读取 Unicode 文本。因此，它们会忠实地把那些隐藏指令解读为项目需求的一部分，然后可能在开发者毫无察觉的情况下，执行凭据收集、源码外泄甚至运行任意 Shell 命令等危险动作 。

这就形成了一种“二段式”攻击：恶意包本身完成第一阶段的凭据窃取，而受到污染的 AI 配置文件则把开发者的 AI 工具变成了一个“潜伏的帮凶”，为后续更深入、更持续的信息窃取创造条件。事实上，相关研究已经证实，Claude Code 和 GitHub Copilot 等主流 AI 代理平台，确实会在读取含有不可见 Unicode 指令的 Skill 文件后，执行其中的任意命令 。

惊人的检测速度：从发现到溯源仅用 48 小时

尽管攻击手法诡谲，Socket 的检测体系响应得非常及时。在所有 381 个具备完整时间戳的包版本中，中位检测时间仅为 5 分 27 秒，最快的一次在恶意包发布仅 58 秒后就完成识别 。

正是因为这种快速响应能力，研究人员才能在第一个可疑包出现后的 48 小时内，将那些看似孤立、分散在各仓库里的异常发布串连在一起，最终拼凑出 TrapDoor 这场协同攻击的全貌 。

目前，在 npm、PyPI 和 Crates.io 三个仓库中已确认的 34 个恶意包，均已被通报给各仓库的维护方进行下架处理 。

如果你或你的团队安装了这些包，请立即采取行动

TrapDoor 的破坏力在于它能在你毫无知觉的情况下，把你的凭据和权限全部“复制”走。时间窗口非常有限，建议立刻按以下步骤排查：

第一步：轮换所有已暴露的凭据

• 加密货币钱包：重新生成种子短语，尽快将资产转移到全新钱包。
• 云服务与代码仓库：立刻轮换 AWS IAM 密钥、GitHub Personal Access Token、所有 SSH 密钥对，以及以环境变量形式存储的各类 API 密钥。
• CI/CD：撤销所有用于集成与部署的 OAuth 令牌。

第二步：审查项目锁定文件

• 运行

  npm audit

  、

  pip list

  并检查 Cargo.lock，寻找已公布的 34 个恶意包。
• 用 git 历史记录搜索这些包名，一旦发现匹配，立刻删除，并执行一次干净的依赖重装（clean install）。

第三步：检查 Shell 启动文件

• 仔细检查 ~/.bashrc、~/.zshrc、~/.profile 以及 ~/.config/fish/config.fish，看看有没有可疑的别名设定，或者没有注释的 curl、wget 下载命令。

第四步：审计 Git 钩子

• 排查每一个仓库 .git/hooks/ 目录下的 pre-commit、post-commit、pre-push 等钩子文件，确认没有未被授权的脚本。鉴于攻击的重点之一就是 GitHub 令牌，你的仓库权限随时可能被滥用。

第五步：复查 GitHub Actions 工作流

• 检查 .github/workflows/ 目录下是否有不明来源的 YAML 文件，或者已有的工作流是否被添加了奇怪的 curl / wget 步骤。
• 查看 Actions 运行日志，寻找异常对外网络请求的记录。

第六步：扫描 AI 配置文件是否遭到篡改

• 在所有项目中查找 .cursorrules 和 CLAUDE.md 文件，检查其中是否包含零宽 Unicode 字符。可以使用下面这条正则命令作为快速排查：

grep -P '[\x{200B}-\x{200F}\x{2028}-\x{202F}\x{FEFF}]' .cursorrules CLAUDE.md

• 删除任何可疑的文件，必要时通过十六进制转储进一步验证。

第七步：排查持久化驻留机制

• 检查定时任务（

  crontab -l

  ）、systemd 用户服务（~/.config/systemd/user/）、以及 macOS 下的 LaunchAgents（~/Library/LaunchAgents/），删除任何不明条目。

第八步：在流程中建立防线

• 将供应链安全扫描集成到 CI/CD 流水线中，让可疑包在安装前就“现原形”。
• 考虑引入运行时检测工具，实时监控对钱包文件、SSH 私钥、云凭证以及浏览器数据目录的异常访问行为。