针对加密开发者的软件供应链攻击仍在升级。安全研究人员最新披露，攻击者通过在 npm 仓库发布5个恶意软件包，瞄准以太坊与 Solana 开发者，借助“拼写仿冒”（typosquatting）手法诱导误装，从而窃取私钥并发送给攻击者控制的 Telegram 机器人。此次事件再次表明，黑客的目标早已不限于普通投资者，开发者使用的工具链同样成为高价值攻击入口。
5个恶意 npm 包瞄准两大主流生态
根据安全机构 Socket 的研究，这批恶意包由同一个账户发布，覆盖 Solana 和以太坊生态。其中，4个包针对 Solana 开发者，1个包针对以太坊开发者。研究人员指出，这一攻击活动配有仍在运作的命令与控制基础设施，显示其并非临时试探，而是具备一定组织性的持续行动。
所谓拼写仿冒，是指攻击者创建与知名开源库名称极其相似的包，利用开发者在安装依赖时的拼写失误或辨识疏忽完成渗透。由于这些恶意包在名称、说明文档甚至结构上刻意模仿真实项目，开发者很容易误以为其为官方或兼容版本，从而在无意中将其引入项目环境。
攻击方式：劫持函数调用，暗中外传私钥
此次恶意包的核心逻辑并不复杂，但极具隐蔽性。它们会挂钩开发者常用来处理私钥的函数：当相关函数被调用时，恶意代码会先将私钥发送给攻击者，再返回看似正常的结果。由于程序功能表面上没有异常，开发者往往难以及时察觉。
报道显示，这些包会把窃取到的数据发送到一个硬编码的 Telegram Bot。所有恶意包都使用相同的 Telegram 端点，且机器人 token 与 chat ID 均被直接写入代码中。由于不依赖外部服务器，这套数据外传机制只要 Telegram 机器人保持在线，就能持续运作，降低了传统 C2 服务器被封堵后的失效风险。
值得注意的是，这些包依赖 Node.js 的 global fetch 功能，因此通常要求Node.js 18 或更高版本。若开发环境版本较旧，请求会静默失败，意味着不会实际完成数据窃取。但这并不构成安全保障，因为大量现代 JavaScript 开发环境已升级至对应版本，现实中的暴露面依然不小。
Solana 与以太坊分别如何中招
在 Solana 方向，4个恶意包主要围绕 Base58 相关处理逻辑展开。研究人员指出，这些包会拦截 Base58 的 decode() 调用，从而截获开发者传入的敏感密钥材料。比如，raydium-bs58 是最直接的样本，它修改了解码函数，在返回结果前先发送密钥；其 README 还复制自合法 SDK，作者字段却为空，显示出明显伪装痕迹。
另一个名为 base-x-64 的 Solana 恶意包则采用代码混淆方式隐藏载荷，通过 Telegram 发送被窃取的密钥。bs58-basic 本身未直接包含恶意代码，但它依赖 base-x-64，形成链式传递，使恶意行为更难在初步审查中被发现。
在以太坊方向，恶意包 ethersproject-wallet 仿冒真实库 @ethersproject/wallet。研究显示，该包是在复制真实库基础上，编译后额外插入了一行恶意代码。更关键的是，这一变化只出现在编译产物中，而不是常规源码位置，说明攻击者进行了人工篡改，意在绕过一般性的代码比对与审查。
多个证据指向同一攻击者
安全研究人员表示，这些包之间存在多个共性：使用同一个数据回传端点、存在相似的拼写错误、共享构建产物，甚至有两个包使用了相同的编译文件，另一个包还直接依赖其中之一。种种线索表明，这并非零散模仿，而更像是同一行为者按统一工作流批量投放的攻击活动。
其中一个恶意包虽然在发布后5分钟内即被下架，但它仍然成功隐藏了恶意代码，并具备向攻击者发送窃取数据的能力。这说明，软件供应链攻击并不一定需要长时间暴露才会造成影响，短暂上线的恶意依赖同样可能击中自动化安装流程或开发者测试环境。
市场与行业影响：供应链安全风险再度升温
从市场层面看，此类事件虽然不会像交易所黑客攻击那样立即冲击代币价格，但会持续削弱开发者与机构对开源依赖生态的信任。以太坊和 Solana 作为活跃度极高的公链生态，其开发工具链一旦频繁遭遇投毒事件，可能推高项目方的安全审计成本，并延缓新产品上线节奏。
更深层的影响在于，私钥与助记词一旦从开发环境泄露，受害者损失往往是不可逆的。对于钱包开发、脚本自动化、做市、节点运维以及 DeFi 协议部署团队而言，开发环境中保存的热钱包权限可能直接关联真实资金，风险远高于普通软件项目。研究人员也明确提醒，任何在此次攻击中泄露的私钥都应视为已彻底失陷，相关资产需尽快转移至新钱包。
事实上，黑客近来持续加码针对开发者的攻击。报道还提到，曾有攻击者通过伪造 OpenClaw 安装程序感染178名 macOS 开发者。该恶意安装器一度出现在 npm 仓库中，目标同样是窃取私钥、助记词及其他敏感数据。连续事件说明，开发者正成为加密行业安全链条中最需重点保护的一环。
开发者应如何应对
目前，安全研究人员已向 npm 提交下架请求。对开发者而言，最现实的应对措施包括：严格核对包名与发布者信息；优先使用官方文档中的依赖地址；审查锁定文件与间接依赖；对处理私钥的代码路径进行单独监控；避免在开发机长期存放高权限热钱包。此外，团队应建立依赖引入审批和镜像仓库机制，减少直接从公共源安装未知包的风险。
总体来看，这起事件再次敲响警钟：在加密行业，攻击面已从用户端、交易平台延伸至开发者工具链。随着攻击者越来越擅长利用开源生态中的信任机制，项目团队若忽视供应链安全，付出的代价可能不仅是代码被污染，更可能是链上资产在无声无息中被转走。