夜雨聆风
5月22日，一个GitHub账号叫「ddjidd564」的用户向知名开源项目browser-use提交了一份Pull Request。
看起来像一次正常的代码贡献，但当安全研究机构Socket.dev在审查该代码贡献时，发现其中包含一个隐藏的配置文件。
该文件利用零宽字符技术（Zero-width characters）指向了一个由攻击者控制的GitHub Pages页面。当AI编程助手读取该文件时，会触发一个伪装成的“安全扫描”程序，而该程序的实质功能是静默窃取开发者的SSH密钥、云服务凭证以及加密货币钱包私钥。
这是一场被命名为“TrapDoor”的协同供应链攻击行动。该行动同时横跨npm、PyPI和Crates.io三大主流代码仓库，共涉及34个恶意包和384个版本变体，攻击目标直接指向加密货币、去中心化金融（DeFi）以及人工智能领域的开发者。
与常规的代码投毒不同，TrapDoor行动通过三条路径并行推进：
多仓库同步触发机制： 攻击者在不同生态中采用了定制化的触发手段。在npm包中利用postinstall钩子在安装后自动执行；在Rust的Crates.io包中利用build.rs在编译阶段触发；在PyPI包中则在模块被导入（import）时远程下载并执行JavaScript。
真实开源项目渗透： 攻击者向活跃的开源项目提交Pull Request，试图将恶意配置注入到具备高频使用量的代码库中，browser-use便是受害者之一。
AI编程助手向量化利用： 攻击者将AI编程助手本身转化为攻击媒介。Cursor、Claude Code和GitHub Copilot等工具在运行时需要读取项目配置文件以理解上下文。攻击者在这些文件中嵌入用零宽Unicode字符隐藏的指令，诱导AI助手访问伪装成“DeFi安全最佳实践”的页面。该页面内容通过误导AI助手执行所谓的安全审计，从而将开发者的敏感数据打包外发。
Socket.dev的检测数据显示：从恶意包上传到标记，平均时间只有5分56秒。最快的58秒。但这场攻击经过精心的提前布局。攻击者在GitHub上准备了完整的文档体系：AUDIT-MATRIX.md描述提取框架和伪装层，BYPASS.md记录绕过检测的手法，SWARM.md规划规模化扩散策略。这不是脚本小子。这是一个有工程纪律的团队。
被窃取的数据清单足以让开发者后背发凉：SSH密钥、AWS凭证、GitHub Token、浏览器登录数据库、主流区块链钱包密钥文件，以及环境变量中的所有API Key。更可怕的是，攻击者还部署了凭证验证机制——偷来的密钥会先被测试是否有效，有效的优先处理，无效的直接丢弃。这是一套典型的工业化数据分级流程。
但比“偷了什么”更可怕的是“怎么留下来”。
恶意代码一旦潜入开发者机器，就会将启动指令深植于系统的多个角落：写入Git hooks，每次提交代码时触发；写入Shell配置文件，每次打开终端时触发；创建systemd服务和cron定时任务，实现系统启动和定时执行。它甚至能通过窃取的SSH密钥，横向移动到同一网络内的其他机器。
其中一个名叫dev-env-bootstrapper的npm包尤其危险。它既是恶意包本身，又充当其他恶意包的传播载体。意味着即使某个包被清除，只要这个「母体」还在，它能把其他包重新拉回来。加密体系也分了两层：npm端用Fernet和ECDH，Crates.io端用XOR加密。
截至5月26日，部分恶意包仍然存活在仓库中。这场攻击还没有结束。
Pillar Security的分析师指出了一个更深层的问题。这不是某个AI工具特有的漏洞。Cursor、Claude Code、GitHub Copilot都会读取项目配置文件，都可能被同一个恶意文件诱导。问题是系统性的。整个「AI助手读取项目上下文」的范式本身，在设计时没有把安全边界考虑进去。
*本文由 AI 辅助撰写，内容经人工审核后发布。*
