近日，一场名为 TrapDoor 的软件供应链攻击活动引发安全行业关注。攻击者将恶意代码包装成正常开发工具，并陆续投放至 npm、PyPI 和 Crates.io 三大软件包生态。
已披露的信息显示，此次攻击涉及 34 个恶意软件包和数百个相关版本。与传统恶意依赖攻击不同，TrapDoor 并不只是简单植入后门，而是将开发者使用的云服务凭证、SSH 密钥以及加密货币钱包等高价值数据作为重点目标。
为了降低开发者警惕，攻击者使用了大量看起来较为正常的软件包名称，并将其包装成安全检测、智能开发、区块链辅助等类型的工具。
其中，部分恶意包名称涉及 AI、Solidity、DeFi 等热门开发方向。这种命名方式能够增加软件包在搜索、测试或开发过程中的曝光概率，一旦开发者误将其加入项目依赖，恶意代码便可能获得执行机会。
此次攻击尤其关注 加密货币、DeFi、Solana、Sui、Aptos 以及 AI 开发相关人员，意味着攻击者并非单纯追求感染数量，而是在主动寻找拥有高价值数字资产或开发权限的目标。
为了适应不同的软件包生态，TrapDoor 并没有使用完全相同的攻击手段，而是针对各个平台的运行机制分别设计执行方式。
在 npm 环境中，恶意软件包可利用安装阶段的脚本触发载荷，进一步运行核心恶意代码；在 PyPI 环境中，则可以借助 Python 包导入过程触发后续行为，并从外部位置获取新的 JavaScript 载荷。
针对 Crates.io 的攻击则利用 Rust 项目的 build.rs 构建脚本，在编译阶段执行相关操作，并进一步寻找开发环境中的 Sui、Move 等区块链项目密钥信息。
这种跨生态设计增加了攻击覆盖面，也意味着开发者仅仅检查软件包表面的功能描述，并不足以发现潜在风险。
TrapDoor 在成功执行后，会尝试搜索受害设备中的多种敏感信息，包括：
SSH 私钥、AWS 环境变量、GitHub 等开发平台令牌、浏览器配置数据，以及 Solana、Sui、Aptos 等相关钱包和开发密钥。
攻击者还会对获取到的部分凭证进行有效性验证，从而判断这些数据是否仍然能够用于访问真实服务。
更值得注意的是，被窃取的 SSH 凭证还可能被进一步用于访问其他服务器。如果开发人员的电脑能够直接连接企业内部开发机、测试服务器或生产环境，一台开发终端失陷后，攻击范围就可能继续向企业内部基础设施扩散。
此次攻击并非单纯执行一次数据窃取。
相关恶意载荷还设计了多种持久化方式，包括利用 systemd 服务、Cron 定时任务、Git Hooks 以及 Shell 启动配置 等机制，使恶意程序能够在系统重启或开发者重新进入工作环境后继续运行。
这意味着即便恶意依赖已经从项目中删除，如果系统中的持久化组件没有被同步清理，攻击者仍有可能继续获取设备中的敏感数据。
TrapDoor 另一个值得关注的特点，是攻击者开始将 AI 编码助手的项目配置文件作为供应链攻击的一部分。
攻击者尝试修改 .cursorrules、CLAUDE.md 等能够影响 AI 编码工具行为的项目文件，并利用不易被肉眼发现的 Unicode 字符隐藏指令。
当开发人员使用 AI Agent 或编码助手分析项目、执行安全检查、运行命令时，这些隐藏内容可能影响 AI 对任务的理解，使原本正常的自动化操作被引导至攻击者设计的执行流程。
相比传统恶意代码，这种攻击方式增加了一层“AI 指令供应链”风险：开发者不仅需要检查程序代码和第三方依赖，还需要关注仓库中的 Agent 指令、规则文件以及自动化配置。
TrapDoor 事件反映出软件供应链攻击正在从单一恶意依赖，逐步扩展至 软件包注册中心、开发者终端、Git 仓库、云服务凭证以及 AI 编码工具配置等多个环节。
对于开发团队而言，安装来源不明的软件包前，应重点核查软件包发布时间、维护者身份、历史版本、安装脚本以及依赖关系；对突然出现且名称高度贴合热门技术关键词的新软件包，更需要保持警惕。
企业还应减少开发终端长期保存高权限 SSH 私钥和云平台访问密钥，并通过最小权限、凭证定期轮换、依赖锁定、软件成分分析和异常网络行为监控等措施降低风险。
随着 AI Agent 更深入地参与代码编写、测试和自动化运维，.cursorrules、CLAUDE.md 等过去容易被忽略的配置文件，也有必要逐步纳入代码审计和供应链安全检查范围。
网站资讯
渠道合作
解决方案
更多服务
