2026年3月末、広く使われているHTTPライブラリ Axios がサプライチェーン攻撃の標的になりました。
サプライチェーン攻撃とは、利用者が普段から信頼しているソフトウェアや配布経路を悪用して、マルウェアを届ける手口です。今回の事件は「有名なライブラリが乗っ取られた」という単純な話ではなく、現代のソフトウェア開発が持つ構造的な脆弱性を突いた、非常に巧妙なものでした。
本記事は、Elastic Security Labsが公開した調査・分析レポートを中心にもとにまとめています。技術的な詳細や検知ルールについては、ぜひElastic Security Labsの公式記事 またはElasticのJoe DesimoneさんがGithub Gistで公開しているものを直接ご参照ください。
何が起きたのか
攻撃者はAxiosメンテナーのnpmアカウントを乗っ取り、悪意あるバージョン（axios@1.14.1 と axios@0.30.4）をnpmに公開しました。通常、Axiosは GitHub Actions を経由した公開フローを採用していますが、今回は通常とは異なる公開経路が使われた可能性があり、直接CLIから公開されたとみられています。
この悪意あるバージョンには、plain-crypto-js@4.2.1 という不正な依存パッケージが仕込まれていました。パッケージには postinstall という仕組みがあり、インストール完了後に自動でコードを実行できます。今回はこれを悪用して setup.js が自動起動し、攻撃者のコードが走る状態になっていました。
つまり、利用者は npm installをしただけで、知らぬ間に攻撃者のコードを実行してしまう可能性がありました。
Huntressの観測によると、パッケージ公開からわずか 89秒後 に最初の感染が確認されています。公開時間が短くても、被害は十分に広がることが証明されました。
なお、問題はAxiosそのものではなく、配布経路が一時的に侵害された点にあります。
なぜこれほど危険だったのか
① 自分でAxiosを入れていなくても感染する
Axiosは非常に広く使われているため、別のパッケージが内部で依存しているケース（トランジティブ依存）も多くあります。「自分のプロジェクトにAxiosはない」と思っていても、気づかないうちに入っていた、というケースが起こり得ます。
② バグでも脆弱性でもない攻撃だった
今回はCVEやゼロデイ脆弱性を突いたものではありません。信頼された公開経路そのものが武器にされた事件です。どれだけコードが安全でも、配布フローが侵害されれば意味をなしません。
③ Windows・macOS・Linuxすべてが対象
setup.js は難読化されており、実行時にOSを判別してそれぞれに対応したマルウェアを起動します。開発者のPC、CI/CDパイプライン、本番サーバーまで、環境を問わず標的になり得ました。
Elasticはどう検知していたのか
Elastic Security Labsが注目したのは、ドメイン名やファイルハッシュではなく、プロセスの実行チェーンです。これはエンドポイント上の振る舞い（EDR的な観点）に基づく検知であり、「何が実行されたか」ではなく「どのように実行されたか」に着目しています。
node 起動 → OSコマンド実行 → 外部からファイル取得 → 実行
正規のパッケージインストールでは、このような流れは通常起きません。攻撃者はドメイン名やファイル名を変えることはできますが、npm install 直後のこの不自然な実行の連鎖はそう簡単には変えられない、という考え方です。
OSごとの検知シグナルも具体的に示されています。Linuxでは node 後の sh/curl 起動とPythonスクリプトの実行、Windowsではエンコードされた PowerShell の実行と永続化の試み、macOSでは osascript の利用や不審なパスへのファイル配置が観測されました。
さらにElasticは、この問題を把握した後に GitHub Security Advisory を提出し、検知ルールと詳細分析を公開するなど、情報共有にも積極的に動いていました。
1つの設計思想から生まれた攻撃
Elasticの詳細分析（”One RAT to Rule Them All”）によると、OS別に異なるマルウェアが使われていたように見えて、実際には通信構造とコマンド体系が共通していました。
実装言語はOSごとに違っても、攻撃者はクロスプラットフォームで動く1つの統一されたRAT（遠隔操作マルウェア）運用を設計していたと考えられます。これは場当たり的な攻撃ではなく、計画的・組織的に準備された攻撃であることを示しています。
感染が疑われる場合の対応
Huntressは、影響を受けたバージョンを導入していた場合、ファイルを削除して終わりにしてはいけないと強く警告しています。
RATが一度動いてしまうと、何が参照・持ち出されたかを完全に特定することは困難です。推奨される対応は以下の通りです。
- 資格情報・トークンのローテーション
- 影響範囲の徹底調査
- 必要に応じた環境の再構築
「マルウェアを消した」ことと「安全が戻った」ことは別物です。特にシークレットやアクセストークンが置かれるCI/CD環境では、侵害前提の対応が求められます。
この事例が示すもの
今回のAxios事件は、オープンソースを使うこと自体が危険だという話ではありません。むしろ、依存関係が当たり前になった現代の開発では、守るべき対象も「コードの品質」から「サプライチェーン全体の信頼性」へと広がっていることを示した事件です。
89秒で感染が始まるスピードは、人手による確認だけでは対応が追いつかないことを如実に示しています。固定のIOCに頼るだけでなく、インストール直後の不自然な実行チェーンを監視する仕組みを持てているかどうか、今一度見直すきっかけにしてください。
参考元
