安全研究机构 Socket 近日披露，一场面向加密开发者的软件供应链攻击正在影响以太坊与 Solana 生态。研究人员发现，攻击者通过发布5个恶意 npm 软件包，利用“typosquatting（拼写仿冒）”手法伪装成常用加密库，从而诱导开发者误装，最终窃取私钥等敏感数据。
所谓 typosquatting，是指攻击者注册与知名依赖包名称高度相似的包名，借助开发者手误、复制粘贴疏忽或审查不严等场景实施投毒。在本次事件中，恶意包主要覆盖4个面向 Solana 开发者的包以及1个面向以太坊开发者的包，均由同一账号发布，且共享相同的命令控制基础设施特征。
攻击方式：劫持私钥处理流程并回传Telegram
根据披露信息，这些恶意包的核心逻辑并不复杂，但隐蔽性较强。它们会“挂钩”开发者在应用中调用的私钥相关函数：当目标函数执行时，恶意代码会先把获取到的密钥发送给攻击者控制的Telegram 机器人，随后再返回正常结果。对开发者而言，程序表面上依旧正常运行，因此攻击往往不易被第一时间察觉。
具体来看，针对 Solana 的恶意包会拦截 Base58 的 decode() 调用，因为 Solana 生态中私钥和密钥材料常通过相关编码处理；而针对以太坊的恶意包则盯上了钱包构造流程，仿冒包 ethersproject-wallet 模仿真实库 @ethersproject/wallet，并在编译产物中插入额外恶意代码。研究人员指出，这一改动只出现在编译后的文件中，说明存在明显的人工篡改痕迹。
此外，所有恶意包都将窃取到的数据发送至同一个 Telegram 端点，且其bot token 和 chat ID 被硬编码在包内。这意味着攻击者并未依赖额外的外部服务器，而是直接借助 Telegram 作为数据回传通道。只要该机器人保持在线，窃密链路就能持续工作。
受影响包与技术细节值得警惕
在已识别样本中，raydium-bs58 的实现最为直接：它修改解码函数，在返回结果前发送密钥数据。其 README 文档复制自合法 SDK，作者字段则为空，具备典型的仿冒特征。另一个面向 Solana 的包 base-x-64 使用了代码混淆来隐藏恶意载荷，并通过 Telegram 发送被盗密钥。
bs58-basic 本身并未直接包含恶意逻辑，但它依赖 base-x-64，从而通过依赖链间接完成攻击。此类“二跳投毒”方式对审计提出更高要求，因为开发者即便检查顶层包，也可能忽视其下游依赖风险。
研究人员还指出，所有样本都依赖 global fetch，这意味着攻击需在Node.js 18 或更高版本环境下才能顺利回传数据；在更旧版本中，请求会静默失败，因而不会完成窃取。这一细节也提醒开发团队，在升级运行时环境时，安全测试不应仅关注兼容性，也要同步审查依赖行为变化。
事件影响：开发者成为加密攻击新前线
此次事件再次表明，黑客的重点目标已不再局限于普通投资者。随着链上应用、钱包工具和基础设施持续扩张，开发者正成为高价值攻击入口。一旦私钥、部署密钥或测试环境凭证在开发阶段泄露，风险可能迅速外溢至项目金库、热钱包、自动化脚本，甚至用户资产。
从市场影响看，此类事件虽然未必立即引发主流代币价格剧烈波动，但会持续削弱市场对开源依赖和 Web3 开发环境的信任。尤其是以太坊与 Solana 这类开发者活跃、生态扩张迅速的公链，其项目高度依赖开源包管理体系。若供应链安全问题频繁出现，可能抬高团队审计与运维成本，并促使机构投资者对项目安全治理提出更高要求。
对项目方而言，短期内最现实的压力来自应急排查与资产迁移。安全研究人员已向 npm 提交下架请求，但对于已经泄露的私钥，风险并不会因恶意包移除而自动消失。研究人员明确表示，凡是因本次攻击暴露的私钥都应视为已被攻破，相关资金需要尽快转移到新钱包。
开发者应如何应对
在防范层面，开发团队应优先核查近期新增依赖，重点比对包名、作者信息、下载量、发布时间与 GitHub 仓库对应关系；同时锁定依赖版本，避免自动拉取未经审查的新包。对于涉及私钥处理、签名、编码解码的钱包模块，更应进行静态与动态审计，确认是否存在异常网络请求或 Telegram、HTTP 回传行为。
值得注意的是，这并非孤立事件。报道还提到，黑客此前曾通过一个伪造的 OpenClaw 安装器感染了178名 macOS 开发者，相关恶意程序一度出现在 npm 注册表中，目标同样是私钥、助记词及其他敏感数据。这说明，围绕开发工具链发起的攻击正在呈现持续化、自动化趋势。
总体来看，本次仿冒 npm 包事件再次给加密行业敲响警钟：在去中心化应用快速迭代的同时，软件供应链已成为最脆弱也最容易被忽视的一环。对于以太坊和 Solana 开发者而言，代码正确性之外，依赖来源可信度、构建过程可验证性以及密钥隔离机制，正日益成为决定项目安全边界的关键因素。