
Injective SDK npm包后门攻击私钥和种子短语
@Injectivelabs/sdk-ts v1.20.21 在被移除之前下载了310次,研究人员敦促对任何暴露的钱包进行密钥轮换。
一个供应链漏洞影响了Injective广泛使用的@injectivelabs/sdk-ts npm包,攻击者修改了版本1.20.21以窃取钱包私钥和助记词。恶意版本已被移除并弃用,但研究人员警告,任何受影响包处理的秘密都应视为已被泄露。
关键要点
- 一个恶意的@injectivelabs/sdk-ts版本(v1.20.21)被修改以捕获私钥和助记词,通过挂钩钱包密钥派生函数并通过“虚假遥测”发送数据。
- 尽管特定的受影响版本在310次下载后被撤回,但该SDK的使用量仍然很大,约为每周50,000次下载。
- 曝光风险不仅限于直接安装,因为v1.20.21在Injective Labs npm范围内的17个其他包中被固定。
- 研究人员建议将通过受影响包传递的任何密钥或助记词视为已被泄露,而Injective首席执行官Eric Chen表示问题已解决,并且“网络上的资金没有风险”,受影响的版本已被弃用。
Injective 的 npm SDK 后门针对钱包秘密
一个软件供应链攻击通过在 @injectivelabs/sdk-ts npm 包中植入后门,破坏了 Injective 开发工具。Socket 的安全研究人员披露,版本 1.20.21 被修改以窃取加密钱包的私钥和种子短语(助记词),这直接影响了钱包安全,而不是协议层面的失败。
恶意代码已被移除。Injective 首席执行官 Eric Chen 表示:“问题已经解决,受影响的 npm 版本已被弃用。”并补充道:“网络上的资金没有风险,”将此事件框定为一个依赖性漏洞,可能影响运行受影响构建的开发者和用户,而不是 Injective 链本身。
v1.20.21 如何通过“虚假遥测”泄露密钥
Socket的描述直截了当:“恶意释放钩子钱包密钥派生函数,记录私钥和助记词,并通过虚假遥测将其导出,”这意味着正常的钱包创建或派生流程可能会悄悄泄露秘密。
入侵路径很重要。Socket 将修改与一个被攻陷的开发者 GitHub 账户关联起来,自 6 月 8 日起开始出现可疑的提交。这为在此期间安装或构建受影响依赖项的任何人创造了明显的风险窗口。
外泄被设计成隐蔽。被盗的数据被编码并发送到一个网络地址伪装成一个合法的Injective网络服务器,旨在进行凭证盗窃,以避免破坏应用程序或触发即时警报。
爆炸半径:50,000 每周下载和 17 个固定包
该软件包的规模是操作问题。@injectivelabs/sdk-ts 每周下载量约为 50,000 次,而 Socket 将该足迹称为“对处理 Injective 钱包工作流的开发者和应用程序来说是重要的”。在被移除之前,特定的恶意版本被下载了 310 次,这表明 v1.20.21 本身的确认分发有限,但不一定意味着下游曝光有限。
二阶风险是依赖传播。Socket 表示 v1.20.21 在 Injective Labs npm 范围内的其他 17 个软件包中被固定,“暴露了可能没有直接安装 SDK 的用户。”在实践中,固定的依赖项可以通过传递安装将受损版本拉入构建,从而扩大受影响应用程序的范围,超出那些自愿升级 SDK 的团队。
修复不仅仅是“更新并继续”。Socket 警告说:“通过受影响的软件包传递的任何密钥或助记符应视为已被泄露,”这意味着对于任何接触过受损代码的秘密需要进行钱包迁移和密钥轮换。Socket 还表示,开发者的账户被入侵后迅速发现了泄露,但警告说“该活动本身尚未完全控制”,这使得额外受影响的版本或软件包存在不确定性。
为什么供应链钱包盗窃在加密货币中不断出现
这一事件符合一个模式:攻击者越来越多地针对像 npm 和 GitHub 这样的可信分发渠道,而不是试图破解链加密。安全联盟(SEAL)警告说,“受损的系统被用来直接将恶意代码推送到公司的 GitHub 仓库,将一次单一的泄露转变为下一个的分发渠道,”并指出恶意软件正在变得更广泛,“包括 macOS 特定活动的增加,结合了信息窃取者、RAT(远程访问木马)和后门功能于一个软件包中。”
激励是明确的。CertiK 报告称,钱包泄露是 2026 年上半年最昂贵的攻击向量,共有 33 起事件造成 4.44 亿美元的损失。
后续行动现在比最初的披露更为重要。交易者和 DeFi 用户应关注该活动是否已完全控制,是否有任何额外的 Injective 范围软件包受到影响,超出 @injectivelabs/sdk-ts v1.20.21,以及是否确认有任何被盗资金来自于经过受影响构建的密钥。在开发者方面,信号是公开修复:在 Injective Labs npm 范围内的弃用状态,以及在潜在曝光后主要项目是否确认密钥轮换或钱包迁移。
将此视为钱包风险事件,而不是链故障故事
我将此视为一个钱包泄露设置,对于在入侵窗口期间接触依赖项的任何人来说,具有不对称的下行风险,而不是一个应该机械性地重新定价 Injective 链风险的协议漏洞。陈的“网络上的资金没有风险”与这种框架一致,但并不减少开发者和高级用户的紧迫感,因为盗窃目标是控制钱包的秘密材料。
重要的阈值是下游的损失是否归因于通过受影响的软件包派生或处理的密钥。如果这种关联出现,并且在 Injective dApps 中的修复仍然不均匀,那么这个设置开始看起来是结构性的,而不是叙事驱动的,因为这将把供应链事件转化为真实的、重复的钱包损失。