Axios npm供应链攻击与“假Claude”应用：软件信任正成为新的攻击面

Axios本身并不是恶意软件，Anthropic的Claude也没有被证明存在同样性质的问题。真正发生的是：攻击者利用了Axios维护者的发布权限，向特定版本植入恶意依赖；SilverFox则制作了冒充Claude品牌的伪造安装程序。

两起事件的技术路径不同，但核心套路高度相似——借助可信的软件信号，让恶意代码看起来像正常的开发工具或生产力应用。

Axios事件：一次例行安装如何变成入侵起点

2026年3月31日，攻击者通过被入侵的维护者账号，在npm仓库发布了两个恶意版本：axios@1.14.1和axios@0.30.4。这两个版本都加入了隐藏依赖plain-crypto-js@4.2.1。该依赖并未用于Axios的正常功能，主要作用是执行恶意安装脚本。

脚本会连接攻击者控制的命令与控制服务器，并根据主机系统下载针对Windows、macOS或Linux的远程访问木马（RAT）。因此，开发者或自动化系统只要在暴露窗口内执行一次普通的

npm install

根据Google威胁情报团队的记录，恶意版本在3月31日协调世界时00:21至03:20之间处于活动状态，其他报告则将其概括为约两到三个小时。Axios是JavaScript生态中使用极其广泛的HTTP客户端库，公开估算显示其每周npm下载量约为8,000万至超过1亿次，但不同来源的统计并不一致。

短暂的上线时间并不意味着风险有限。依赖更新、持续集成（CI）任务和构建流水线都可能自动拉取新版本，受影响的设备数量因此不会只局限于手动查看软件包的开发者。Huntress报告称，在其客户范围内至少确认了135台受影响设备。

被利用的是发布信任，而不是Axios功能漏洞

现有公开信息更支持“npm维护者账号或发布凭据被劫持”的判断，而不是Axios代码本身存在一个被直接利用的漏洞。部分报道认为，攻击者使用了主维护者的长期有效npm访问令牌；其他报告则较为谨慎，只描述为维护者账号或发布凭据遭到入侵。

这一差别十分关键。攻击者突破的，是“维护者发布权限—npm发布流水线”之间的信任边界。由于恶意版本是通过合法账号发布的，下游开发者和自动化系统很难仅凭发布者身份将其判定为可疑。

恶意依赖隐藏了什么

plain-crypto-js@4.2.1看上去像普通的加密相关依赖，但它实际通过postinstall脚本执行安装阶段的恶意操作。脚本会联系命令与控制服务器，并下载适配受害主机操作系统的第二阶段载荷。

这意味着攻击者不需要诱导开发者直接运行一个明显可疑的可执行文件。一次依赖升级、一次CI构建，甚至暴露窗口内自动执行的

npm install

Axios攻击究竟与BlueNoroff有关吗？

目前公开材料中的归因并未形成统一结论。部分报告将这次行动与朝鲜关联的BlueNoroff或其他相关团伙联系起来；微软则将该事件归因于Sapphire Sleet。

因此，BlueNoroff更适合被描述为一条技术归因线索，而不是已经完全证实的结论。代码、基础设施和行动方式之间的相似性可以支持调查方向，但单凭这些重叠，无法证明具体由哪个团伙实施。

较为稳妥的事实判断是：Axios事件涉及维护者账号被劫持、恶意版本发布，以及针对三大桌面操作系统的RAT投放；至于背后的攻击者，公开评估仍存在分歧。

SilverFox如何利用“假Claude”进入企业

SilverFox采用了另一种入口：分发适用于Windows、macOS和Linux的伪造Claude应用。根据卡巴斯基全球研究与分析团队（GReAT）的相关分析，该活动针对印度、印度尼西亚、南非和俄罗斯的组织，涉及工业、咨询、贸易和运输等行业。

这些应用并非Anthropic官方Claude安装程序，而是冒充Claude品牌的恶意软件。攻击场景非常符合企业日常工作：员工搜索一款AI生产力工具，下载看似熟悉的应用，安装后却将恶意代码带入工作设备。卡巴斯基称，SilverFox自2025年12月以来已在多个波次中开展相关活动。

从“税务通知”转向AI诱饵

在使用假AI应用之前，SilverFox还曾利用税务主题开展钓鱼活动。研究人员在2026年1月至2月期间记录到超过1,600封恶意邮件，这些邮件伪装成官方税务审计通知，或声称附件中包含“税务违规名单”。

投递方式发生了变化，但攻击者利用的信任信号并没有改变：税务通知制造紧迫感和权威感，品牌化的AI助手则提供了相关性与便利感。两者都可能促使收件人在核实来源前打开附件、下载压缩包或安装软件。

SilverFox还采用分阶段投递模式，为入侵的不同阶段使用相互分离的基础设施。这样一来，防守方更难仅凭一个域名或单一指标识别并拦截完整攻击链。

两起事件的共同教训：信任本身就是攻击面

Axios和SilverFox瞄准的是不同的信任关系：

• 维护者信任： Axios版本看起来是由获得授权的npm发布者推出的。
• 依赖信任： 包管理器将恶意依赖视为正常安装路径的一部分。
• 品牌信任： 假Claude安装程序借用了知名AI产品的身份。
• 工作流信任： 开发者和员工只是执行了日常操作——更新依赖或安装生产力软件。

Axios事件说明，暴露窗口很短也可能造成广泛影响。自动化构建、CI/CD流水线和依赖更新可以在数分钟内拉取受污染的软件包；SilverFox事件则表明，随着企业越来越多地采用AI工具，“下载一个AI助手”正在成为可信度很高的新诱饵。

换句话说，熟悉的软件名称不是安全证明，合法的发布账号也不等于每个版本都可信；同样，知名产品的名称也不能证明每一个安装程序都来自官方。

企业现在应该做什么

针对Axios事件，组织应检查锁文件、包清单、构建日志、缓存、依赖清单和CI环境，搜索以下项目：

• axios@1.14.1
• axios@0.30.4
• plain-crypto-js@4.2.1

在暴露窗口内安装过受影响版本的设备，应进一步排查是否存在下载载荷、未授权持久化机制和凭据泄露。相关安全建议明确要求将这些安装视为潜在入侵事件处理。

对于AI软件，企业应要求员工通过批准的渠道获取桌面应用，核对发布者信息和下载域名，并对未经批准的安装程序进行阻断或隔离。

在npm发布环节，启用抗钓鱼多因素认证、使用短期或严格限定权限的凭据、验证软件发布来源（provenance）、维护锁文件，并对依赖变更进行审查，都有助于降低单个账号失陷演变为供应链事件的风险。

真正需要建立的，不只是某一个产品的安全检查，而是每个信任边界上的验证机制：包名要验证，发布者要验证，版本变更要验证，安装来源也要验证。