JavaScriptの定番HTTPクライアント「axios」をめぐり、npm上で配布された一部バージョンに悪意ある依存関係が混入していたことが判明した。問題の版は axios@1.14.1 と axios@0.30.4 で、公開分析によれば、主要メンテナーのnpmアカウント、またはその長期有効トークンが侵害され、通常のGitHub Actions経由ではない形で不正公開された可能性が高い。これは「axios本体の脆弱性」ではなく、正規パッケージの配布経路そのものが汚染されたサプライチェーン攻撃だ。
攻撃者は axios 本体に大きな改変を加える代わりに、plain-crypto-js@4.2.1 という不審な依存パッケージを追加し、その postinstall スクリプトを通じて macOS / Windows / Linux 向けのRAT（Remote Access Trojan、遠隔操作型トロイの木馬） を落とす仕組みを仕込んでいた。
何が起きたのか
StepSecurity と Aikido の分析によると、攻撃は axios の主要メンテナー jasonsaayman にひもづく npm 側の公開権限を悪用する形で行われた。npm の登録メールアドレスは ifstap@proton.me に変更されており、正規リリースで通常見られる GitHub Actions の Trusted Publisher / OIDC による公開痕跡も確認されていない。さらに GitHub 側には 1.14.1 に対応するタグが見当たらず、通常のリリースフローから外れた不正公開だった可能性が高い。
Socket の分析でも、問題の axios 版はソースコードを派手に書き換えた形ではなく、依存関係を1本だけ静かに差し込む「最小改変」 だったとされる。クリーン版の 1.14.0 / 0.30.3 には存在しない plain-crypto-js@^4.2.1 が追加され、これがインストール時に自動実行されることで、利用者の端末やCI環境に第2段階ペイロードを配布する設計だった。
時系列で見る今回の流れ
公開分析に基づく時系列は次の通りだ。まず 2026年3月30日 14:57 JST に、一見無害な plain-crypto-js@4.2.0 が公開された。続いて 3月31日 08:59 JST に悪性の 4.2.1 が公開され、09:21 JST に axios@1.14.1、10:00 JST に axios@0.30.4 が公開された。さらに 12:15 JSTごろ に npm から問題の axios 版が取り下げられ、12:25 JST に plain-crypto-js への security hold が始まり、13:26 JST には security-holder スタブが公開されている。
露出時間は長くなかったが、axios は npm エコシステムでも特に広く使われる基盤ライブラリだ。StepSecurity は 3億件超/週、Aikido と Socket は 約1億件/週 と見積もっており、数字には差があるものの、短時間でも影響が大きくなりうる規模 である点は共通している。特に ^1.14.0 や ^0.30.0 のような範囲指定、あるいは自動ビルド・自動更新を行う CI/CD 環境では、短い露出時間でも十分に危険だった。
マルウェアは何をしていたのか
Socket による静的解析では、plain-crypto-js@4.2.1 の setup.js は難読化された多段式ドロッパーで、OSを判定して Windows / Linux / macOS 向けの別々のペイロード配布処理 に分岐する。公開説明では、任意コマンド実行、情報窃取、永続化が可能な RAT とされている。StepSecurity も、C2（Command and Control、攻撃者の操作サーバ）に接続し、OS別の第2段階ペイロード を取得すると説明している。
厄介なのは、実行後に証拠を消す設計 だ。Aikido は node_modules を後から見ても分からない場合がある と警告しており、Socket も setup.js を削除し、package.json を差し替えて postinstall の痕跡を薄める流れを示している。つまり、「node_modules を見て怪しいファイルがないから安全」とは言えない。被害確認にはログ、lockfile、端末上のIOC（Indicators of Compromise、侵害指標）の確認が必要になる。
現時点で分かっている影響範囲
現時点で特に危険とされるのは、問題の版を実際にインストールした開発マシン、CIランナー、ビルドサーバー だ。Aikido は axios@1.14.1 または 0.30.4 を導入していたなら、侵害済み前提で動くべきだ としている。確認用の痕跡としては、Windows では %PROGRAMDATA%\wt.exe、macOS では /Library/Caches/com.apple.act.mond、Linux では /tmp/ld.py などが挙げられている。
一方で、単にWebサービスの利用者である一般ユーザー まで直ちに影響が及ぶタイプの事件とは、現時点では言いにくい。今回の感染トリガーは、あくまで 悪性版のインストール時に postinstall が走ること だからだ。被害の中心は npm を使って依存関係を解決する開発フロー側にある。
いまの最新状況
Aikido は 問題の2バージョンはすでに npm から削除済み としており、StepSecurity も latest の dist-tag は 1.14.0 に戻った と報告している。npm 上の axios パッケージページでも、現時点の公開版は 1.14.0 と表示されている。つまり、焦点は 「まだ配布中か」ではなく、「露出時間中にどの環境が踏んだか」 に移っている。
ただし、被害企業数や感染台数の全体像はまだ公表されていない。Socket もこの件を active and developing incident と位置づけており、現段階では技術分析、公開タイムライン、IOC、対処手順が主な公開情報となっている。なお Socket は、@shadanai/openclaw や @qqbrowser/openclaw-qbot といった周辺パッケージでも、同じドロッパー経路が確認されたとしている。
開発者・運用担当者が取るべき対応
対応方針はおおむね一致している。まず、axios@1.14.1 と axios@0.30.4、および plain-crypto-js@4.2.1 の有無を、依存関係、lockfile、npmログで確認すること。そのうえで、影響が見つかった環境では 安全版への固定 に加え、資格情報のローテーション、影響端末の再構築、CIシークレットの再発行 を検討すべきだ。Aikido は安全版として 1.14.0 と 0.30.3 を挙げている。
- まず axios@1.14.1 / 0.30.4 / plain-crypto-js@4.2.1 の混入有無を確認する
- 影響があれば axios 1.x は 1.14.0、0.x は 0.30.3 に固定する
- npmトークン、クラウド鍵、SSH鍵、CIシークレット、.env値 など、当該環境で参照可能だった資格情報をローテーションする
- IOC が見つかった端末は、その場での「掃除」ではなく、既知の安全状態からの再構築 を優先する
ひとことで言うと
今回の axios 事件は、「人気OSSに脆弱性が見つかった」話ではなく、「信頼されていた配布ルートが、短時間だけだが本物のマルウェア配送路になった」事件 だ。露出時間は数時間規模でも、対象が axios 級の基盤パッケージだったことで、npm エコシステム全体の供給網リスク を改めて突きつけるケースになっている。
情報源
- StepSecurity「axios Compromised on npm - Malicious Versions Drop Remote Access Trojan」2026-03-30
https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan - Aikido「axios compromised on npm: maintainer account hijacked, RAT deployed」2026-03-30
https://www.aikido.dev/blog/axios-npm-compromised-maintainer-hijacked-rat - Socket「Supply Chain Attack on Axios Pulls Malicious Dependency from npm」2026-03-31
https://socket.dev/blog/axios-npm-package-compromised - GitHub Issue「axios@1.14.1 and axios@0.30.4 are compromised #10604」2026-03-31
https://github.com/axios/axios/issues/10604 - npm「Axios」 package page（現時点の公開版表示）
https://www.npmjs.com/package/axios
