Axios npmパッケージの侵害：何が起きたのか、何が重要なのか、そしてどう対応するか

Axiosのnpmパッケージ侵害事件で何が起きたのか

Axiosのnpmパッケージが侵害されたというこの事例は、現代のソフトウェアリスクが、必ずしも従来のCVEやソースコードで公開された脆弱性という形で現れるわけではないことを改めて思い起こさせてくれます。 場合によっては、本当の問題は、改ざんされたパッケージのリリースや、汚染された依存関係チェーン、そして通常の更新作業をセキュリティインシデントへと変えてしまうインストール時の実行パスにあることがあります。

セキュリティおよびITチームにとって、喫緊の課題は単に「Axiosは影響を受けたのか？」ということだけではありません。 しかし、「実際にどのバージョンが影響を受けているのか、何が実行されたのか、そして今、何を再構築したり調査したりする必要があるのか？」

最近の業界レポート（ ）によると、 攻撃者がメンテナーのアカウントを乗っ取った後、 npm に悪意のあるAxiosパッケージのバージョンを公開したとのことです。  の悪意のあるリリースにより、 のメインブランチおよびレガシー バージョン の両方に影響が及んだと報告されており、主にインストール時の実行を誘発するために存在していた依存関係が導入されました。

[Linux管理者の方へ：特権のないユーザーにroot権限への実質的な経路を提供してしまうカーネルの権限昇格脆弱性「Copy Fail」について、知っておくべきことをご紹介します]

 の重要な点は、 こちらです： Axios自体は、遠隔から悪用可能なソフトウェアのバグという従来の意味での「悪用」を受けたわけではありません。 その代わりに、リスクは のソフトウェアサプライチェーンに起因していました。

この事件がなぜ重要なのか

Sonatype（ ）によると、の 2025年において、主要なオープンソースレジストリ全体で 454,600 件以上の新たな悪意のあるパッケージが特定されたエコシステムにおいて、Axiosは最も広く利用されているJavaScript HTTPクライアントの一つです。
Axiosは以下の場所で利用されています：

• 開発者向けワークステーション
• CI/CDランナー
• ビルドサーバー
• 一時的なクラウドワークロード
• 依存関係を動的にインストールする本番環境システム

広く採用されているパッケージが侵害された場合、その影響範囲は、パッケージの人気度そのものよりも、むしろ、侵害が発生していた期間中に、実際に影響を受けるバージョンを解決・インストールした環境の数がどれほどあったかによって決まります。

週間のダウンロード数により、Axiosはnpmエコシステムにおいて最も広く利用されているJavaScript HTTPクライアントライブラリの一つとなりました。つまり、 2026年3月 によるサプライチェーン攻撃の際、たとえ短期間の脆弱性露出期間であったとしても、甚大な影響が生じる可能性があったということです。

[Vercelのセキュリティインシデントに関する当社の分析記事をお読みいただき、OAuthの信頼関係がどのように悪用されたのか、影響範囲の特定がなぜ困難だったのか、そしてこの侵害事件が現代のIDを悪用した攻撃について何を明らかにしているのかをご理解ください]

報告されている悪意のあるバージョン

公開されている報告によると、悪意のあるものとして最も頻繁に特定されたバージョンは以下の通りです：

また、公開された分析では、この妥協点が、インストール後の動作をトリガーするために使用されていた予期せぬ依存関係と関連付けられていました。

お使いの環境に、これらのパッケージのバージョンや、上記の予期せぬ依存関係が含まれている場合は、さらに詳しく調査すべき強い兆候である可能性があります。

による独立したリバースエンジニアリングおよび脅威分析によると、 2026年3月 でのサプライチェーン侵害が発生した当時、npm エコシステム内の依存パッケージが Axios に依存していたことが判明しており、これは悪意のあるパッケージの公開が引き起こし得る影響範囲の広さを示しています。

Axiosのnpmパッケージへの不正アクセスが、通常の脆弱性とはなぜ異なるのか

ほとんどの脆弱性対策プログラムは、既知の脆弱性、影響を受けるバージョンの範囲、およびパッチ適用に関する指針に基づいて設計されています。 このイベントは、いくつかの重要な点でそのモデルを打ち破っています。

これは単なるコードの不具合ではなく、パッケージ・トラストの問題でした

このリスクは、悪意のある公開イベントに起因するものでした。 つまり、

• 対応の根拠となるCVEが存在しない可能性があります
• パッケージのメタデータは、ソースコードと同じくらい重要です
• 依存関係の解決の挙動が、攻撃対象領域の一部となります
• インストールスクリプトやインストール後のフックが、重要な証拠となります

依存関係のパスを対象としました

多くのチームは、依然として のpackage.json（）における直接的な依存関係に重点を置いています。 しかし、サプライチェーン攻撃の多くは、侵害された依存関係に起因していることから、このようなインシデントは、推移的依存関係やファントム依存関係がなぜ重要なのかを浮き彫りにしています。

そのため、従来のアプリ審査だけでは不十分となります。

これは、さまざまなオペレーティングシステムに対応していました。

公開されている調査によると、このインストールチェーンにより、Windows、macOS、Linuxの各プラットフォームで固有の挙動が生じたことが示されています。 それが重要なのは、対応が「開発者のノートPCに関するリスク」や「Linuxビルドエージェントに関するリスク」にとどまってはならないからです。 チームには、プラットフォームを横断した可視性が必要です。

セキュリティチームがまず行うべきこと

サプライチェーンにおけるインシデントでは、チームは実際の状況を把握する前に、早合点して憶測に走ってしまうことがよくあります。 指標を追いかける前に、まずは最もシンプルな質問から始めましょう：

この環境内のどこかに、影響を受けるパッケージのバージョンはありますか？

その順序が重要なんです。

まずは「存在感」から始め、次に「行動」へと進み、最後にその「影響」を評価します

実用的な対応モデルは、次のようなものになります：

このアプローチにより、ノイズを低減し、チームが見出しに過剰反応することを防ぎつつ、実際のリスクに対しては迅速に対応できるようになります。

環境において注目すべき点

Axiosのnpmパッケージの侵害による潜在的な影響を評価される場合は、エンドポイント、サーバー、CI/CDシステムを横断して、パッケージの痕跡、プロセスの動作、ファイルの痕跡、およびネットワークアクティビティの組み合わせを確認してください。

パッケージレベルのエビデンス

以下の点をご確認ください：

• axios バージョン 1.14.1
• axios バージョン 0.30.4
• plain-crypto-js バージョン 4.2.1
• 予期せぬ依存関係の解決を引き起こしたロックファイルの変更
• 既知の曝露期間中のパッケージのインストール

エンドポイントおよびワークロードに関する実証データ

プラットフォームに応じて、調査担当者は、インストール時のスクリプト実行、段階的なペイロードのダウンロード、あるいはNode.jsやnpmから生成された不審な子プロセスなど、これらと一致する兆候を探すべきです。

役立つカテゴリには、次のようなものがあります：

• npm または node によって起動されたシェルまたはスクリプトの実行
• パッケージのインストール後に、予期しない PowerShell、Python、curl、またはシェルの動作が発生する
• ファイルが一時ディレクトリに書き込みを行います
• 名前が変更された、または偽装されたバイナリ
• 分離されたバックグラウンドプロセス
• 開発者またはビルドシステムからの異常な送信トラフィック

CI/CDの実績

ビルドパイプラインには、次のような特徴がしばしば見られるため、特に注意を払う必要があります：

• 幅広いネットワークへのアクセス
• 注入されたシークレット
• クラウドの認証情報
• デプロイメント・トークン
• パッケージの自動解決

CIランナーが悪意のあるパッケージのバージョンをインストールしてしまった場合は、この事象を単なる開発用依存関係の懸念以上のものとして扱ってください。 レビュー：

• ワークフローのログ
• 依存関係の解決のタイミング
• 外部へのネットワーク接続
• その職種で利用できる秘密
• 指定期間中に生成されたビルドのアーティファクトの完全性

直ちに行うべき是正措置

該当するバージョンが使用されていることが確認できたら、迅速かつ着実に作業を進めてください。

以下の対応策は、Axiosのnpmパッケージへの不正アクセスといったサプライチェーン上のインシデントが発生した際に、一般的に講じられる封じ込め措置を反映したものです。 これらは必ずしも決まった順序で実行されることを意図したものではありません。組織は、システムの重要度、承認要件、およびリスク許容度に基づいて、これらを適用する必要があります。

封じ込めチェックリスト

安全な包装衛生管理の変更

その場限りの対応が終わった後も、各チームはパッケージの管理をさらに徹底すべきです：

• 重要な依存関係については、正確なバージョンの固定を推奨します
• コードレビューでロックファイルの妥当性を確認する
• CIでは、可能な限りインストールスクリプトの使用を制限してください
• ビルドのシークレットと、日常的な依存関係の解決を分離する
• パッケージの公開および利用において、出所確認を徹底する
• マニフェストには含まれているものの、実際のアプリケーションでは使用されていないパッケージを監視します

TaniumがAxiosのサプライチェーンに関するインシデントの対応にどのように役立つか

、Tanium Guardian、 の「Axiosサプライチェーン侵害ダッシュボード」は、セキュリティおよびITチームが、自社の環境内に侵害されたAxiosパッケージが存在するかどうかを迅速に把握し、該当する場合は潜在的な影響を調査するのに役立ちます。

このダッシュボードは、まず影響範囲の特定に重点を置いており、チームは のTanium SBOM（ ）データを活用して、脆弱性が確認されたAxiosのバージョン（v1.14.1 およびv0.30.4 のレガシー版）を追跡し、影響を受けるパッケージが自社の環境内のどこかに導入されているかどうかを判断することができます。 これにより、セキュリティチームやITチームは憶測の域を脱し、サプライチェーンインシデントにおいて最も差し迫った疑問、すなわち「侵害されたソフトウェアが実際に存在しているかどうか」という問いに答えることが可能になります。

詳細な調査機能が有効になっている組織向けに、このダッシュボードは、macOS、Windows、Linuxを横断するクロスプラットフォームの「Stage 2 」調査をサポートしており、悪意のある依存関係に関連するRATの痕跡や、潜在的なコマンド＆コントロール活動を特定するのに役立ちます。

のTanium Threat Response（ ）が利用可能な場合、チームは影響を受けたエンドポイントを隔離するなどの対応措置を講じることもできます。

ダッシュボードの全機能を利用するには、Tanium SBOM および Tanium Threat Response が導入されており、Tanium のエクスポージャーの検証、調査、および対応に対するモジュール型アプローチを反映した、適切なレポート作成および閲覧権限が設定されている必要があります。

SBOMデータが対応の在り方を変える理由

のソフトウェア部品表（ ）は、コンプライアンス上の資料として扱われることがありますが、CISA、NSA、および 19 の国際パートナー は、その採用が不可欠なセキュリティ上のマイルストーンであると宣言しています。 このような出来事は、その見方がなぜ狭すぎるのかを示しています。

パッケージの改ざんが発生した場合、SBOMデータを活用することで、影響を受けたパッケージがどのビルド成果物に含まれていたか、どのバージョンが含まれていたか、また関連する不審な依存関係が宣言されていたかどうかを特定するのに役立ちます。 それらのアーティファクトがどこにデプロイされたか、あるいはどのシステムがパッケージをインストールしたかを特定するには、エンドポイント、コンテナ、およびパイプラインに関する追加のテレメトリデータが必要となります。

そうした可視性がなければ、チームは概算値に頼りがちになります：

• リポジトリ検索
• 開発者による自己申告
• 不完全なEDRの手がかり
• ロックファイルの手動確認
• 「インストールすべき」ものに関する前提

それらは有益な情報ですが、環境レベルでの証拠に代わるものではありません。

SBOM 対 仮定に基づく優先順位付け

SBOMに基づく優先順位付けは、リポジトリやアラートのみから推測されるものではなく、エンドポイント上に実際に存在する内容に基づいています。

StepSecurityの分析（ ）によると、この侵害は予期せぬ依存関係（plain-crypto-js）の注入に起因しており、 、Axiosのソースコードの改変によるものではありませんでした。これは、サプライチェーン上のインシデントにおいて、SBOMのようなコンポーネントレベルの可視性がなぜ重要であるかを如実に示しています。

避けるべきよくある間違い

Axiosのnpmパッケージの侵害に対応するチームは、予想されたいくつかの落とし穴に注意を払う必要があります。 以下の例は、このようなサプライチェーン上のインシデントでよく見られるパターンを反映したものですが、実際の対応方針については、各組織のアーキテクチャ、リスク許容度、および運用環境に基づいて決定する必要があります。

これを「単なる開発者の問題」として扱うこと

CI環境で改ざんされたパッケージが実行された場合、そのリスクは個々の開発者のワークステーションにとどまらず、認証情報、ビルド成果物、および下流の環境にまで及ぶ可能性があります。 多くの組織において、CIシステムは開発者のエンドポイントよりも広範なアクセス権と高い権限を有しています。

Axiosの直接的な使用例のみを探しています

Axiosへの依存関係は、Axiosを直接の依存関係として明示的に宣言しているアプリケーションに限定されない可能性があります。 そのパッケージは、推移的な依存関係パスや、一時的なビルドコンテキスト、あるいは初期のトラブルシューティングの段階では見落としがちな短命な環境に存在している可能性があります。

CVEが確認されていないと仮定すると、緊急度は低いということになります

サプライチェーンの脆弱性は、従来の の脆弱性管理ワークフローには明確には当てはまらないものの、実際の運用リスクをもたらす可能性があります。。 CVE に基づく優先順位付けに慣れているチームは、既知の脆弱性識別子に対応しないパッケージの信頼性に関する事象を過小評価してしまう可能性があります。

実行が確認された後のその場洗浄

悪意のある行為が確認された場合、特に特権環境や機密情報が多い環境では、その場でのクリーンアップを試みるよりも、正常な状態から再構築するほうが、多くの場合、より安全です。 適切な対応は、システム上の役割、権限レベル、および機密性の高い認証情報への接触状況によって異なります。

調査ワークフローの例

以下の手順は、Axiosのnpmパッケージが侵害されたようなインシデントに対し、セキュリティチームとITチームが調査をどのように進めるかの一例を示しています。 これはあくまで一例であり、厳格なチェックリストではありません。組織のツール、環境、リスクプロファイルに応じて適宜調整してください。

フェーズ1：被ばくの確認

• 影響を受けるAxiosのバージョンを含む在庫管理システム
• 不審な、あるいは予期しない関連依存関係が存在するかどうかを特定します
• 曝露期間中にパッケージのインストールが行われた場所をマッピングする

フェーズ 2：実行状況の調査

• npm および Node.js の子プロセスを確認する
• 一時ファイルの作成およびシェルの起動を確認してください
• 不審なスクリプトインタプリタや、切り離されたプロセスを探してください
• 影響を受けたホストからのアウトバウンドネットワーク接続を関連付けます

フェーズ 3：下流への影響を評価する

• 認証情報やシークレットにアクセス可能だったかどうかを確認してください
• 対象期間中に生成されたビルド成果物の変更内容を確認してください
• 持続性または二次ペイロードの配信に関する指標を評価する
• 確信度とリスクに基づいて、クリーンアップと再構築のどちらを行うかを決定してください。

フェーズ 4：強化

• 依存関係を、安全性が確認されているバージョンに固定する
• 可能な限り、インストールスクリプトの公開範囲を縮小してください
• 依存関係およびSBOMのカバレッジを向上させる
• CIのシークレット管理を強化する
• パブリッシャーの信頼性と出所管理について確認する

この種の対応を体系化しようとする組織にとって、より広範な の脆弱性露出管理（ ）およびのコンプライアンス対策（ ）は、影響を受ける資産全体にわたる脆弱性の発見、優先順位付け、および是正措置を連携させるのに役立ちます。その一方で、環境固有のリスクに応じた柔軟性も確保できます。

Axiosのインシデントに関するよくある質問

Axios自体に脆弱性はあったのでしょうか？

エクスプロイトの手口やパッチが存在するような、一般的な意味でのソフトウェアの欠陥ではありません。 この問題は、悪意のあるパッケージの公開に伴うサプライチェーンの侵害でした。

どのバージョンのAxiosが影響を受けると報告されましたか？

公開された報告では、この事件に関連する悪意のあるnpmリリースとして、一貫して「axios 1.14.1 」および「axios 0.30.4 」が指摘されています。

Axiosのnpmパッケージへの不正アクセスは、短期間のことだったとしても、なぜ重要なのでしょうか？

なぜなら、短期間のパッケージの脆弱性であっても、その影響を受ける期間中に問題のあるバージョンが解決・インストールされてしまうと、依然として高価値なシステムに影響を及ぼす可能性があるからです。 速やかな削除を行っても、すでに完了したインストールは元に戻りません。

組織は認証情報をローテーションすべきでしょうか？

影響を受けるパッケージが、シークレット、トークン、クラウド認証情報、またはデプロイメントキーにアクセスできるシステムにインストールされていた場合は、対応の一環として、認証情報の確認と更新を行う必要があります。

ソースリポジトリを確認するだけで十分でしょうか？

いいえ。Repoのレビューは参考にはなりますが、エンドポイント、ビルドエージェント、およびワークロード全体に実際に何がインストールされていたかを証明するものではありません。 環境レベルの可視性（ ）は不可欠であり、Tanium などのツールはエンドポイントのファイルやプロセスのテレメトリ情報を提供できますが、パッケージの存在確認には、多くの場合、追加のアートファクト、リポジトリ、およびパイプラインのデータが必要となります。

Axiosのnpmパッケージが侵害された事件から得られる、より大きな教訓

成熟したインシデント対応は、脆弱性フィードだけに依存するものではありません。 これには、3つの根拠に基づいた質問に素早く答える能力が求められます：

1. 問題のあるパッケージは、実際にはどこにあるのでしょうか？
2. インストール後にどのような現象が発生しましたか？
3. その結果、業務にどのような影響が生じましたか？

セキュリティチームにとって、それは「ニュースの見出しに反応する」ことと「事実に基づいて対応する」ことの違いなのです。 同様の教訓 は、最近のサプライチェーン関連のインシデント においても明らかになっています。例えば、 XZ Utils や 3CX、 といった事例では、信頼されていた開発者のアクセス権やビルドインフラが悪用され、バックドアが仕込まれていました。こうした事例は、チームがCVEのみに基づいてソフトウェアのリスクを過度に狭く評価することを避けるべきである理由を改めて裏付けています。

その他の参考資料

• Tanium Guardian Axios サプライチェーン侵害ダッシュボード
• Axiosのウェブサイト
• OpenSourceMalware コミュニティの脅威データベース「Axios」への不正アクセスに関する分析
• Elastic Securityの技術分析

ソフトウェアが実際にインストールされ、実行されているエンドポイント、サーバー、ビルド環境全体における依存関係の露出をどのように検証すべきか、チームで再検討されている場合、Taniumは、実際の導入状況を把握することから始め、体系的なアプローチで動作を調査し、検証済みのリアルタイムなエンドポイントインテリジェンスを活用して対応できるよう、チームを支援します。 お客様の環境に合わせてカスタマイズされた の無料デモをご予約ください。