Axiosのサプライチェーン攻撃とは何だったのか

2026年3月31日、JavaScriptの代表的なHTTPクライアントであるAxiosで、深刻なサプライチェーン攻撃が確認されました。影響を受けたのはニュースメディアのAxiosではなく、npmで広く利用されているOSSライブラリのaxiosです。今回の事案は、単なる脆弱性公表ではありません。正規のメンテナー権限が侵害され、信頼されていたパッケージ自体がマルウェア配布の経路になった点に本質があります。JavaScriptライブラリ、npm、依存関係、CI/CD、開発端末という、現代のソフトウェア開発に欠かせない基盤がまとめて狙われた事例として、今後も長く参照される可能性があります。

contents

何が起きたか ―Axiosのnpmパッケージに不正版が公開

Google Cloud Blogで公開された「North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack」によると、2026年3月31日00:21 世界標準時（UTC）から03:20 UTCの間に、axiosのnpm公開版のうち1.14.1と0.30.4へ悪意ある依存関係が混入しました。問題の依存関係はplain-crypto-jsで、これは通常のAxios機能に必要なものではなく、postinstallフックを通じてインストール時に自動実行されるよう細工されていました。つまり、影響を受けた環境では、アプリケーションがAxiosを使ったかどうかではなく、その版をnpm installした時点で不正コード実行の可能性が生じる構造でした。

AxiosのGitHub Issue #10604でも、axios@1.14.1とaxios@0.30.4が侵害されていたことが公に共有されています。公式issue自体は技術詳細が少ないものの、外部研究者からの指摘が速やかに可視化されたことで、npm配布物とGitHub上の正規ソースの間に乖離が生じていたことが早期に認識されました。

本質は「脆弱性」でなく「信頼の乗っ取り」

本事案を理解するうえで重要なのは、Axios本体のコード品質に起因する一般的な脆弱性とは性質が違う点です。StepSecurityの公式Blog「axios Compromised on npm – Malicious Versions Drop Remote Access Trojan」によると、攻撃者はAxiosメンテナーのnpmアカウントを侵害し、通常のGitHub Actions経由のTrusted Publisherではなく、盗まれた認証情報を使って悪性版を公開したとのことです。正規リリースではGitHub Actions由来の公開痕跡が見える一方、問題の1.14.1ではそのパターンが崩れており、さらにGitHub側に対応するコミットやタグも確認できませんでした。これは、開発者が「公式パッケージだから安全」と判断しやすい場所そのものが改ざんされたことを意味します。ソフトウェアサプライチェーン攻撃が危険視される理由はここにあります。アプリケーション開発者は通常、依存パッケージを全面的に目視監査しません。しかもAxiosは週あたり1億回規模で利用される人気ライブラリであり、上流の1パッケージが汚染されるだけで、その影響は大量の開発環境、ビルドサーバー、CIランナー、社内アプリケーションへ連鎖する可能性があります。Google Cloud Blog（前段参照）では今回の事案による影響は広範にわたる、と警告しており、単発のnpm事故では済まない可能性を示しています。

悪性版Axiosはどのように動いたのか

Google Cloud Blogによると、混入されたplain-crypto-jsは難読化されたドロッパーであり、Windows、macOS、Linuxを対象にWaveShaper.V2のバックドアを展開したとのことです。package.jsonのpostinstallによってバックグラウンドでsetup.jsが実行されるため、開発者の体感としては、ただ依存関係を導入しただけに見えます。Socket公式ブログ「Supply Chain Attack on Axios Pulls Malicious Dependency from npm」やStepSecurityブログ（前段参照）でも、plain-crypto-jsは本来のAxios機能では参照されておらず、マルウェア配布のためだけに差し込まれた依存関係だった、と整理しています。さらにStepSecuritは、当該ドロッパーがC2へ接続し、OSごとの第2段階ペイロードを取得した後、自己削除やpackage.jsonの正常化で痕跡隠蔽を試みると説明しています。ここが企業実務では特に重要です。単に「悪い版を消して入れ直せば終わり」ではなく、インストールを実行した開発端末やCI環境そのものを侵害前提で確認すべき、という判断につながるからです。

影響を受けるのはどんな企業か

影響範囲は、Axiosを直接使うWebアプリ開発チームに限りません。Socketは、^1.14.0や^0.30.0のようなキャレット範囲指定をしていたプロジェクトでは、次回のnpm install時に不正版を取得し得たと指摘しています。つまり、明示的に最新版へ上げた覚えがなくても、自動解決で悪性版を拾う余地がありました。この特徴はnpm運用の現実とよく一致しており、依存関係を日常的に更新する開発現場ほど巻き込まれる可能性が高まります。

また、企業内で見落とされやすいのがCI/CDパイプラインです。StepSecurityは、問題の版が公開されていた時間帯にnpm installやnpm ciを実行したビルド環境を重点確認対象として挙げています。開発者PCだけでなく、CIランナー、検証環境、コンテナビルド基盤、さらにはその先の秘密情報管理まで連鎖確認が必要になります。サプライチェーン攻撃は「ライブラリの問題」だけに限らず、認証情報の流出、ビルド改ざん、社内への横展開まで発展する可能性があるのです。

北朝鮮系脅威アクターとの関連は？

Google Cloud Blogでは今回の活動は北朝鮮のハッカー集団「UNC1069」が関与している、と指摘しています。理由として、「WaveShaper.V2」のバックドアを使用している点や攻撃インフラと過去活動の重なりが示されています。

企業は何をもって「影響あり」と判断すべきか

まず確認すべきなのは、2026年3月31日の短い公開ウィンドウの間に、axios@1.14.1またはaxios@0.30.4、あるいはplain-crypto-js@4.2.1を取得した痕跡があるかどうかです。

StepSecurityは、ローカルリポジトリやpackage-lock.json、node_modules内の痕跡確認方法を示しています。Cybozuの注意喚起でも、日本時間の2026年3月31日9:21〜12:15ごろに該当処理を行った環境は、問題のあるAxiosをインストールした可能性があるとしています。日本企業にとっては、この日本標準時（JST）での切り替えが実務上わかりやすい基準となります。ただし、痕跡確認で「見つからなかった」というだけでは完全に安心できません。今回のペイロードは痕跡隠蔽も伴うため、その時間帯にビルドや依存更新を実行した環境は、ログ、ネットワーク通信、認証情報利用履歴まで含めて点検したほうがよいです。特にCI環境にクラウド資格情報や署名鍵、デプロイトークンを置いている組織は優先度が高いでしょう。サプライチェーン攻撃では、初動対応の遅れが二次被害につながります。

今回のAxios事案で推奨される初動対応

今回の事案で重要なのは、単なるパッケージの差し替えではなく、侵害前提のインシデントレスポンスです。StepSecurityでは、axios@1.14.1または0.30.4をインストールしていれば、システム侵害を前提として扱うべきだとしています。これはドロッパー型マルウェアと開発環境侵害の組み合わせを考えると、合理的な判断といえます。少なくとも、端末隔離、トークンや認証情報のローテーション、CIシークレットの再発行、該当ジョブやコンテナの洗い替え、関連ログの保存は必要になるでしょう。

また、依存関係の修正では、問題のある版を避けて既知の正常版へ戻す必要があります。StepSecurityブログの比較によると、axios@1.14.0および0.30.3には問題のplain-crypto-js依存が存在しません。したがって、少なくとも悪性版から即時ロールバックする対象としてこの二つは確認済みのクリーン版といえます。将来的な正式後継版の採用は、Axios側による公式情報や検証結果を見て判断するのが安全でしょう。

なぜAxiosのサプライチェーン攻撃はここまで注目されたのか

理由は主に３つ挙げられます。第一に、AxiosがJavaScript開発で極めて広く使われていることです。第二に、ソースコードレベルでは目立ちにくい依存関係の一点差し替えで成立していたことです。第三に、Windows、macOS、Linuxの全方位を狙うクロスプラットフォーム型だったことです。GoogleもElasticも、この事案を単発のnpm汚染ではなく、最近続いているオープンソース供給網攻撃の流れの中で捉えています。つまり、OSSの人気パッケージを踏み台にして開発者環境を取るという攻撃モデルが、今後さらに一般化する可能性があります。

企業の情報システム部門やセキュリティ担当者にとって重要なのは、「脆弱性管理だけではこの種の攻撃を十分に捉えきれない」という点です。今回のようなAxiosのサプライチェーン攻撃では、CVEの有無より先に、配布経路、署名・公開フロー、依存解決、CI実行タイミングがリスクの中心になります。ソフトウェア部品表、依存関係監視、公開直後版のクールダウン、Trusted Publisherの徹底、CIシークレット分離といった運用論が、一気に現実味を帯びたといえます。

Axiosのサプライチェーン攻撃から企業が学ぶべきこと

本事案は、「有名ライブラリだから安全」「公式アカウントから出た版だから安全」という前提が崩れたことを示しています。開発の現場では、依存ライブラリの更新を迅速化するほど生産性は上がりますが、その一方で悪性版を取り込むリスクも高まります。そのため今後は、すべての更新を遅くするのではなく、公開直後の版に対する短い待機期間、異常依存の検知、ビルド時の外部通信監視、重要トークンの短命化といった、現実的な防御策を重ねることが必要になります。特に経営層は、本事案を「OSS（オープンソースソフトウェア）利用の危険性」と短絡的に考えるべきではありません。OSSは現代開発の基盤であり、排除は現実的ではありません。問われるのは、OSSを使う前提でどう監視し、どう公開フローを信頼し、どう侵害時に被害を限定するかということです。Axiosのサプライチェーン攻撃は、その問題を開発部門だけでなく、情シス、CSIRT、監査、経営まで広げた事件として位置づけるべきでしょう。

まとめ

Axiosのサプライチェーン攻撃は、2026年3月31日に発生したnpm改ざん事案であり、axios@1.14.1とaxios@0.30.4に悪性依存関係plain-crypto-js@4.2.1が混入していました。インストール時のpostinstallでクロスプラットフォームのRAT（Remote Access Trojan）配布が行われる構造で、影響判定の中心は「使ったかどうか」ではなく、その時間帯にその版を取得したかどうかです。もし該当版を導入していれば、パッケージの入れ替えだけで済ませず、開発端末やCI環境を侵害前提で調査し、認証情報のローテーションまで含めて対応する必要があります。今回の事件は、npm、JavaScript、依存関係管理の問題、そしてサプライチェーン攻撃対策を考えるうえで、2026年を代表するケースの一つになるでしょう。

サイバーインシデント緊急対応

セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。