フィッシング対策LOCKED ATP

axiosのサプライチェーン攻撃リスク：2026年3月の実被害事案と防御策

公開日: 2026年9月18日

axios は JavaScript / Node.js エコシステムで広く使われているHTTPクライアントライブラリで、npmにおける週間ダウンロード数は1億件規模にのぼります。2026年3月末、その axios 自体がメンテナアカウント乗っ取りを起点としたサプライチェーン攻撃の被害を受け、悪意あるバージョンが約3時間にわたり npm 公式レジストリで配布される事態が発生しました。本記事では、当該事案の概要、axiosのような人気npmパッケージを狙うサプライチェーン攻撃の類型、過去のnpmエコシステムでの事例、そしてSBOM ソフトウェア部品表の活用を含め開発者・組織が取るべき防御策を解説します。

axiosとは：JavaScriptで最も使われるHTTPクライアントの1つ

axiosの位置づけ

axios は Promise ベースのHTTPクライアントで、以下の特性から長年広く採用されてきました。

ブラウザとNode.jsの両方で動作する
リクエスト／レスポンスのインターセプタが扱いやすい
JSONの自動変換、タイムアウト、キャンセルトークンなどの実用機能
主要フレームワーク（React、Vue、Next.js等）のチュートリアルで頻繁に紹介される

このような採用度の高さは、利便性であると同時に「侵害された場合の影響範囲が極めて広い」というリスクの裏返しでもあります。

「人気OSS = サプライチェーンの単一障害点」という構造

現代のWebアプリケーションは、直接importしているライブラリの背後に数百〜数千の推移的依存を抱えるのが普通です。axiosのような中核ライブラリ、あるいはその依存先（過去に話題になった is-promise、colors.js、debug のようなユーティリティ）が侵害されると、上流アプリに広範囲な影響が波及します。

選定ガイド（無料）

フィッシング訓練選定ガイド

フィッシング訓練サービスの選び方を解説。訓練テンプレート、レポーティング、AI活用など、効果的な訓練に必要な機能を比較できます。

無料でダウンロード

2026年3月：axios自体がサプライチェーン攻撃の被害に

事案の概要

Microsoft、Google Threat Intelligence Group（GTIG）、Snyk、StepSecurityなど複数のセキュリティ調査機関の報告によれば、2026年3月30日〜31日にかけて、axios の公式バージョン axios@1.14.1 および axios@0.30.4 が悪意あるパッケージとして npm レジストリに公開されました。検知から削除完了までの公開期間は約3時間にとどまったものの、自動的に依存解決を行う環境では十分な被害が生じうる時間幅です。

攻撃経路

報告されているシナリオは次の通りです。

axios のメンテナの1人である jasonsaayman の npm アカウントが乗っ取られ、登録メールアドレスが攻撃者のものに変更された
攻撃者は axios の依存に plain-crypto-js@4.2.1 を追加した悪意あるバージョンを公開した。この依存パッケージは、広く使われる crypto-js を装ったタイポスクワット型の悪性パッケージ
plain-crypto-js は npm の postinstall フック経由で WAVESHAPER.V2 と呼ばれるリモートアクセス型バックドア（RAT）を macOS / Windows / Linux にドロップする挙動を持つ

帰属

Google GTIG は北朝鮮系脅威アクター UNC1069、Microsoft は同一とみられるアクターを Sapphire Sleet として帰属させています。本件は、人気OSSのメンテナアカウントを起点にした典型的な「世界規模に到達するサプライチェーン攻撃」の実例として位置付けられます。

この事案から学ぶこと

「公式の最新バージョン」であっても無条件に信頼できる前提は崩れた
公開期間がわずか数時間でも、自動デプロイ環境では悪性バージョンが本番に到達しうる
検知の鍵は、依存ツリー全体に対する継続的な可視化（SBOM）と、新規/急増依存への自動アラート
メンテナアカウント保護（MFA・SSO・フィッシング訓練）は、公開側だけでなく利用側組織にとっても自社の被害確率を左右する論点

最新の公式インシデントレポートは、Microsoft Threat Intelligence・GTIG・Snyk・StepSecurity 等の各公開資料を併読することを推奨します。

axiosをめぐるサプライチェーン攻撃のリスク類型

axios自体や、axiosを取り巻く周辺で起こりうる脅威は以下のように整理できます。

1. パッケージそのものの侵害（メンテナアカウント乗っ取り）

OSSのメンテナアカウントが、フィッシング・パスワード再利用・MFA未設定などの理由で乗っ取られ、悪意あるバージョンが公式リポジトリ（npm）に公開されるケースです。利用者から見れば「公式の最新版」に見えるため、検知が極めて困難です。

冒頭で取り上げた2026年3月のaxios事案がまさにこの類型に該当します。過去のnpmエコシステムでも同種事例は繰り返されており、ua-parser-js（2021年10月、複数バージョンに暗号資産マイニング・情報窃取コードが混入）、event-stream（2018年、暗号資産ウォレットCopayを標的としたコードが依存経由で混入）などが代表例です。

2. typosquatting（タイポスクワッティング）

axios を axois のように1文字ずらした名前で偽パッケージを公開し、開発者の打ち間違いを狙う攻撃です。特にコピー&ペーストではなく手入力で npm install する場面で被害が起きやすい類型で、2026年3月の axios 事案で混入した plain-crypto-js（crypto-js を装ったtyposquat）も同じパターンに分類されます。

3. 依存パッケージ経由の汚染

axios自体が無事でも、axiosが依存している（あるいは過去に依存していた）下流ライブラリが侵害されれば、結果としてaxiosをimportするアプリに悪意あるコードが届きます。攻撃者は「直接の人気パッケージ」よりも「人気パッケージから依存される地味なユーティリティ」を狙うことが増えています。

4. 過去CVEの未修正利用

axios自体にも公開済みの脆弱性があります。代表例として、CVE-2023-45857（withCredentials=true 時に XSRF-TOKEN ヘッダがクロスオリジンに漏洩する問題、修正は0.28.0／1.6.0）や、CVE-2025-27152（baseURL 設定下で絶対URL指定によりSSRFおよびクレデンシャル漏洩が発生、修正は1.8.2）などが報告されています。攻撃者は、組織のSBOMが整備されていない／古いバージョンが放置されているという前提を突きます。

5. 偽パッケージ・なりすましのpostinstallスクリプト

npmパッケージは postinstall フックで任意のコードを実行できる仕様のため、npm install した瞬間にデータ窃取や認証情報スキャンを実行する攻撃が成立します。axios関連を装ったパッケージで、この種の攻撃が継続的に観測されています。

npmエコシステムで起きてきた主要なサプライチェーン攻撃

axiosに限らず、npm全体では大規模なサプライチェーン攻撃が継続的に発生しています。代表的な事例から、攻撃者の関心と手口の変遷を確認できます。

年	事例	概要
2018	event-stream	依存チェーンに新規追加された flatmap-stream に、暗号資産ウォレット Copay を標的としたコードが混入
2021	ua-parser-js	メンテナアカウント乗っ取りにより、暗号資産マイニング・情報窃取コードを含むバージョンが公開
2022	node-ipc	メンテナ自身が政治的メッセージを目的とした破壊的コードを意図的に追加（プロテストウェア）
2024	polyfill.io	2024年2月のドメイン所有権移転後、6月に Sansec が悪性スクリプト配信を検知。10万超のサイトに影響
2026	axios	メンテナアカウント乗っ取りにより `axios@1.14.1` `axios@0.30.4` が悪意あるバージョンとして約3時間 npm 公開

これらに共通するのは「利用者は公式の依存関係を信頼してインストールしているだけ」という点です。コードレビュー・WAF・EDRといった従来の防御層では検知しにくく、サプライチェーン特有の対策が必要になります。

開発者・組織が取るべき防御策

1. lockfileによるバージョン固定

package-lock.json / yarn.lock / pnpm-lock.yaml をリポジトリにコミットし、CIでの再現性を担保します。npm install ではなく npm ci を使用することで、lockfileに記録されたハッシュとの整合を強制できます。

2. SBOMの生成と継続スキャン

ビルド時にSBOM（CycloneDX / SPDX）を生成し、Grype・OSV-Scanner・Trivyなどの脆弱性スキャナと連携させます。新たなCVEが公表された際、自社製品のどのバージョンに影響があるかを即座に特定できる体制が、サプライチェーン攻撃時代の前提インフラになります。

3. 依存関係の最小化

「便利だから」という理由で依存を増やすのではなく、「本当に必要か・自前実装で代替可能か」を定期的に棚卸しします。依存ツリーが浅いほど、攻撃面（attack surface）は小さくなります。

4. 新規パッケージ追加時のレビュー

package.json に新規パッケージを追加するPRでは、以下を確認します。

メンテナ・公開元の信頼性（個人 / 企業 / 財団）
直近のリリース頻度（突然のバージョン跳ね上がりは要警戒）
ダウンロード数の不自然な伸び（typosquatting警戒）
リポジトリのスター数・Issue対応状況

Socket、Snyk、Sonatype、GitHub Advanced Securityなどのツールで自動評価する選択肢もあります。

5. CI/CDパイプラインの隔離

npm install を実行する環境が、本番認証情報や顧客データに直接アクセスできる状態は危険です。CI/CDランナーは最小権限で隔離し、postinstall スクリプトが情報を抜き出せないようにネットワーク制限・シークレット分離を徹底します。

6. 開発者アカウントの保護

GitHub・npm・パッケージレジストリの開発者アカウントが乗っ取られれば、SBOMをいくら整備していても悪意あるコードが「公式バージョン」として配布され得ます。MFA強制（できればハードウェアキー）、SSO統合、フィッシング訓練が、サプライチェーン攻撃の入口を塞ぐ最も効果的な対策の1つです。

7. 通信の出口監視

侵害されたパッケージは、攻撃者のC2サーバや認証情報送信先と通信を試みます。アプリケーション・CIランナーの外向き通信を監視・制限することで、被害発覚を早期化できます。

インシデント発生時の対応フロー

axiosを含む依存パッケージで侵害が公表された場合、組織として取るべき初動は以下のようになります。

影響範囲特定：SBOMリポジトリで該当パッケージ・バージョンを利用しているアプリを横断検索
配布停止・ロールバック：影響を受ける可能性があるアプリのデプロイを止め、安全なバージョンへ戻す
認証情報のローテーション：CIランナーや開発者環境で取り扱っていたシークレット・トークンを再発行
通信ログの遡及調査：侵害バージョンが含まれていた期間の外向き通信ログを確認し、データ流出の有無を評価
公式アドバイザリの追跡：GitHub Advisory・OSV・JVNなどで続報を継続的に確認
開発者アカウントの監査：自社の開発者アカウントが侵害されていないかを確認（不審なログイン履歴、MFA状況、トークン発行履歴）

ここで重要なのは、SBOMがなければステップ1の段階で詰まる、という点です。サプライチェーン攻撃時代の備えは、平時の可視化に9割が決まります。

LOCKEDサービスとの関係

サプライチェーン攻撃の最も典型的な侵入経路の1つが、開発者・OSSメンテナを狙った標的型フィッシングです。「リポジトリ管理者宛の偽招待リンク」「npmからを装ったパスワードリセット通知」などは、極めて巧妙化しています。

LOCKED MSO はSSO・MFA統合により、開発者の認証情報が単独で漏れた場合でも侵害連鎖を止める基盤を提供します。LOCKED ATP はAI生成シナリオを活用した標的型フィッシング訓練機能を備え、開発者を含むハイリスク層の組織耐性を底上げできます。

LOCKEDの詳細を見る サプライチェーン攻撃の入口となるアカウント保護・標的型攻撃対策はLOCKEDにご相談ください。資料請求・デモ依頼はこちら →

まとめ：人気OSSに依存するすべての組織がサプライチェーン攻撃の潜在標的

ポイント	内容
axiosのリスク特性	採用範囲が広く、侵害時の影響波及が極めて広い
主な攻撃類型	メンテナアカウント乗っ取り／typosquatting／依存経由汚染／postinstall悪用／過去CVE未修正
平時の備え	lockfile固定／SBOM＋脆弱性スキャン／依存最小化／新規追加時レビュー／CI隔離／開発者アカウント保護
有事の対応	SBOMによる影響範囲特定 → ロールバック → シークレットローテ → 通信ログ調査
本質的な防御	「公式の依存関係を盲信しない」前提で多層防御を組むこと

2026年3月のaxios事案は、人気OSSのメンテナアカウント乗っ取りが現実のリスクであることを明確に示しました。axiosは今後も主要ライブラリとして使われ続ける一方、同様のリスクは npm エコシステム全体に構造的に存在します。「自社が依存しているOSSが侵害される可能性」を前提に運用設計を行うことが、これからの開発組織には不可欠です。