一、事件经过 3月31日00:21（UTC），黑客利用Axios核心维护者被盗的npm账户权限，违规发布了axios@1.14.1和0.30.4两个恶意版本。安全团队确认，这两个版本未经过正常开发流程，而是攻击者使用被盗凭证手动发布。攻击者在依赖链中嵌入了前一天刚注册的伪装包plain-crypto-js，该包在安装时会自动执行恶意脚本。 二、技术分析 此次攻击显示出明显的专业化特征： 1. 攻击者提前18小时发布不含恶意代码的plain-crypto-js@4.2.0以建立“可信”记录，次日再推送带后门的4.2.1版本； 2. 采用双版本并行策略，同时覆盖latest与legacy两条版本分支； 3. 恶意代码具备跨平台能力，分别针对Windows、Linux、macOS投放定制化木马； 4. 攻击链响应极快，从安装到连接控制服务器仅约2秒，并通过多层加密与混淆降低被检测的概率。 三、影响评估 尽管恶意版本在3小时内被下架，但Axios作为周下载量超过1亿次的基础组件，据Wiz公司监测，全球约3%的运行环境在此期间安装并执行了问题版本。另外，约80%的云环境与代码库存在Axios依赖，潜在影响仍可能继续扩散。 四、深层原因 事件暴露出开源生态的三类薄弱环节： 1. 核心维护者账号防护不足，双因素认证等基本措施缺失； 2. npm等平台对新包的安全筛查存在滞后，新注册包更易被利用； 3. 企业对开源组件依赖程度高，但版本锁定与变更管控不足。 五、应对建议 网络安全专家给出分层防御建议： • 立即层面：所有使用Axios的企业应尽快核查依赖版本，升级至官方确认的安全版本； • 中期层面：建立软件物料清单（SBOM），并对依赖关系进行可视化监控； • 长期层面：推动建立开源组件“数字健康证明”体系，将安全审计纳入持续集成与发布流程。
开源软件是数字产业的重要基础。开放协作带来效率，也对身份管理、发布审计和依赖治理提出更高要求。Axios事件表明，供应链安全不是靠单一工具或一次修补就能解决，只有把安全能力融入开发、构建、发布与运行全链条，才能在持续演化的威胁下建立可信的软件基础。