文章总结： 2026年7月9日，InjectiveLabsSDK的npm包@injectivelabs/sdk-ts1.20.21版本被投毒，攻击者利用受信任账号植入后门，影响18个关联包，约49分钟后修复为1.20.23。研究机构建议升级版本并轮换可能泄露的密钥。同日，npm12默认关闭allowScripts并限制绕过2FA的token，生态安全收紧。开发机应视为生产系统上游，需加强依赖锁定、来源校验和最小权限管理。 综合评分： 85 文章分类： 供应链安全,漏洞预警,安全建设,安全工具,解决方案

npm 供应链又中招：一个 SDK 被投毒，为什么开发机也要按生产系统防护

原创

tcode tcode

字节脉搏实验室

2026年7月10日 10:24 北京

在小说阅读器读本章

去阅读

    过去很多团队把“开发机安全”当成办公终端安全的一部分：装个杀软、开个 VPN、别乱点链接。但现在的问题变了。攻击者不一定要直接打你的生产环境，他们可以先污染你信任的依赖、构建流程和发布账号，让开发链条自己把风险带进来。

    7 月 9 日，BleepingComputer 报道称，Injective Labs SDK 项目的 GitHub 仓库遭入侵，攻击者利用该访问权限向 npm 发布恶意包。研究机构 Socket、OX Security、StepSecurity 均对这起供应链事件进行了分析。

事件概述

    公开报道显示，受影响的核心包包括 @injectivelabs/sdk-ts 的 1.20.21 版本。StepSecurity 称，攻击者使用受信任开发者账号访问权限，把后门代码放入 Injective 区块链相关 SDK，并在短时间内影响 18 个关联包；这些包约 49 分钟后被修复并重新发布为 1.20.23。

    OX Security 报告称，相关依赖影响可触达 87 个 downstream dependents，并给出累计下载量约 112,378 的估计。BleepingComputer 报道称，恶意版本在被 deprecated 前已有数百次下载。这里的重点不是单一数字，而是供应链攻击的传播方式：一个高信任依赖被污染，多个直接和传递依赖都会被牵连。

核心事实

    已确认的事实包括：BleepingComputer 2026 年 7 月 9 日报道该事件；StepSecurity 和 OX Security 均在同日发布分析；受影响版本集中在 1.20.21；研究机构建议使用固定后的 1.20.23 版本，并对可能接触过敏感钱包信息的环境做密钥处置。

    同一时间，GitHub 在 2026 年 7 月 8 日发布 npm 12 相关变更：npm v12 已成为 latest，并默认开启安装期安全设置。GitHub 公告称，allowScripts 默认关闭，Git 依赖和远程 URL 依赖也默认需要显式允许；同时 npm 将逐步限制可绕过 2FA 的 granular access tokens 在敏感操作和直接发布上的能力。

    需要区分的是：npm 12 的安全默认值并不是专门针对 Injective 事件发布的补丁；两者只是时间上接近。但把它们放在一起看，可以看到生态层面对供应链攻击的系统性收紧。

影响分析

    这类攻击危险在两个层面。第一，它绕过了很多人的心理防线：开发者安装的是熟悉作用域下的合法包名，不是一个看起来可疑的新包。第二，它可能发生在运行时、构建时或发布链路中，不一定在安装时就表现异常。

    对 Web3、金融、支付和自动化运维项目来说，开发机和 CI 环境往往保存 API Key、钱包密钥、云访问凭证、发布 token 和内部服务权限。如果这些环境没有隔离、没有最小权限、没有安装审计，那么一次依赖投毒就可能变成密钥泄露、资产转移或生产发布链路被接管。

开发团队应对建议

    1. 如果使用过相关 Injective 包，检查 lockfile、依赖树、缓存和制品仓库，确认是否拉取过 1.20.21 版本或受影响关联包。

    2. 对可能接触过钱包私钥、助记词、API Key、npm token、GitHub token 的机器和 CI 任务，按“可能泄露”处理，优先轮换密钥。

    3. 升级到研究机构和项目方建议的干净版本，并避免只更新直接依赖，必须检查传递依赖和私有镜像缓存。

    4. 启用依赖锁定、包来源校验、变更差异审查和异常版本告警，不要让高风险依赖自动无感升级进入生产链路。

    5. 评估 npm 12 安全默认值影响，逐步把可信安装脚本显式 allowlist 化，减少依赖安装阶段的隐式执行。

    6. 将自动发布迁移到 OIDC trusted publishing 或带人工批准的 staged publishing，减少长期 npm publish token 的暴露面。

事实 / 推测 / 观点

    事实：受影响包名、版本、修复版本和传播范围来自 BleepingComputer、StepSecurity、OX Security 报道；npm 12 安全默认值来自 GitHub Changelog。

    推测：使用私有 npm 镜像、缓存或未固定版本的项目，可能在原包被修复后仍保留恶意版本副本，但需要具体环境核查，不能一概而论。

    观点：开发机不再只是“写代码的电脑”，它已经是生产链路的上游。能发布包、访问云、签名制品、读取密钥的开发环境，应按生产系统安全标准管理。

结语

    这起事件和 npm 12 的变更共同指向一个趋势：开源生态正在从“默认信任安装”转向“默认限制执行”。对团队来说，真正要改变的不是一条命令，而是开发供应链的安全模型。依赖可以复用，信任不能无限继承。

关键来源

• BleepingComputer，2026-07-09 04:10 PM，Injective SDK on npm infected with cryptocurrency wallet stealer：https://www.bleepingcomputer.com/news/security/injective-sdk-on-npm-infected-with-cryptocurrency-wallet-stealer/

• StepSecurity，2026-07-09，Injective npm Supply Chain Attack：https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys

• OX Security，2026-07-09，Injectivelabs npm Package Hijacked：https://www.ox.security/blog/injectivelabs-npm-package-hijacked-impacting-87-dependent-packages/

• GitHub Changelog，2026-07-08，npm install-time security and GAT bypass2fa deprecation：https://github.blog/changelog/2026-07-08-npm-install-time-security-and-gat-bypass2fa-deprecation/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：字节脉搏实验室 tcode tcode《npm 供应链又中招：一个 SDK 被投毒，为什么开发机也要按生产系统防护》