Axiosとは何か、今回の問題の概要、今取るべき確認手段と検知時の対応

2026年4月時点の整理

はじめに

2026年3月末、JavaScript界隈で非常に大きなインシデントが発生しました。
広く使われているHTTPクライアントライブラリ Axios のnpm配布物が一時的に改ざんされ、悪意のあるパッケージが正規アップデートを装って配布されたのです。

これは単なる「ライブラリの不具合」ではありません。
開発環境・CI/CD・ビルド基盤そのものが攻撃対象になるサプライチェーン攻撃 であり、企業や開発組織にとっては信用に直結する重大事です。

本記事では、まずAxiosが何かを整理したうえで、今回の問題の概要、今すぐ確認すべきこと、そして万が一検知した場合にどう動くべきかをまとめます。

Axiosとは何か

Axiosは、JavaScript / TypeScript でHTTP通信を行うための定番ライブラリ です。
ブラウザでもNode.jsでも利用でき、APIに対して GET POST PUT DELETE などのリクエストを送るために使われます。

たとえば、以下のような用途でよく利用されます。

フロントエンドからバックエンドAPIを呼び出す
ログイン・会員登録APIを叩く
一覧取得や詳細取得を行う
管理画面から更新・削除処理を行う
Node.jsアプリから外部サービスのREST APIを呼ぶ

サンプルとしては次のようなコードです。

ts
import axios from "axios";

const response = await axios.get("https://example.com/api/users");
console.log(response.data);

Axiosが広く使われる理由は、単にHTTP通信ができるだけでなく、次のような実務向け機能がまとまっているためです。

baseURL の共通化
タイムアウト設定
ヘッダーの共通設定
JSONの扱いやすさ
リクエスト/レスポンスの共通処理
エラーハンドリングの整理
インターセプターによる認証トークン付与など

つまりAxiosは、JavaScriptアプリケーションにおける通信の土台 のような存在です。
それだけに、Axiosの配布経路が侵害された今回の件は影響範囲が大きく、業界全体で強く注目されています。

今回何が起きたのか

今回の本質は、Axios本体のソースコードに脆弱性が見つかったわけではなく、npm上で配布された一部のAxiosバージョンが不正に改ざんされた ことです。

報告されている主なポイントは以下のとおりです。

2026年3月31日、Axiosメンテナーのnpm公開権限が侵害された
悪性バージョンとして axios@1.14.1 と axios@0.30.4 が公開された
これらには plain-crypto-js@4.2.1 という不正依存が混入されていた
インストール時に postinstall が実行され、外部から追加ペイロードを取得する仕組みだった
macOS / Windows / Linux を対象としたクロスプラットフォームRATが導入され得た
問題の公開物は数時間で削除されたが、その間に自動更新やCIで取り込まれた可能性がある

ここで重要なのは、GitHub上のコードを見ても異常に気づきにくい 点です。
今回汚染されたのは「配布物」であり、通常の npm install やCIの依存解決を通じて開発環境に侵入するタイプの攻撃でした。

つまりこれは、アプリ本体の脆弱性対応とは異なり、

開発者PC
CI/CD実行環境
Docker build環境
デプロイ基盤
秘密情報を持つビルドサーバー

といった “信頼された内部環境” を踏み台にできる ことが極めて危険です。

なぜこの問題が重大なのか

今回の件が重大なのは、単にAxiosが人気ライブラリだからではありません。
「正規の依存更新に見える形で、マルウェアを開発基盤へ流し込める」 からです。

通常、開発現場では以下のような運用がよくあります。

npm install を日常的に実行する
RenovateやDependabotで依存更新を自動化する
CIで毎回クリーンインストールする
Docker build時に依存解決を行う
複数プロジェクトで同じライブラリを利用する

こうした仕組みは本来、開発速度や保守性を高めるためのものです。
しかしサプライチェーン攻撃では、この「便利さ」と「自動化」がそのまま攻撃の拡散力になります。

しかも、侵害されるのは本番アプリだけではありません。
攻撃者にとって価値が高いのは、むしろ以下です。

GitHubトークン
npmトークン
AWS / GCP / Azure の認証情報
コンテナレジストリの認証情報
.env のAPIキー
SSH鍵
社内システム接続情報

つまり、ビルド環境や開発環境が持つ“権限”や“信用”そのものが狙われる わけです。

今すぐ取るべき確認手段

今回の件で最初にやるべきことは、「Axiosを使っているか」だけを見ることではありません。
問題のバージョンが、いつ・どこで・実際に解決され、実行されたか を確認することが重要です。

1. 影響バージョンの有無を確認する

まずは以下の悪性バージョンが依存関係に含まれていないか確認します。

axios@1.14.1
axios@0.30.4

確認対象は次のとおりです。

package.json
package-lock.json
npm-shrinkwrap.json
pnpm-lock.yaml
yarn.lock
CIログ
Docker buildログ
キャッシュ済み依存アーティファクト

重要なのは、直接依存だけでなく間接依存も含めて確認すること です。
自分でAxiosを明示的に入れていなくても、他ライブラリ経由で取り込まれている可能性があります。

2. 実際にインストールが走ったか確認する

lockfileに記録があるだけでは不十分です。
問題の時間帯に実際に次のような処理が走ったか確認します。

開発者PCでの npm install
CI/CDでの依存解決
Dockerイメージビルド
自動更新ボットによるPR生成
デプロイ前ビルド

今回のように公開時間が短くても、自動処理がその時間に当たれば影響を受けます。

3. 開発端末・CI環境のログと挙動を確認する

以下のような観点で調査します。

不審な外部通信が発生していないか
想定しない postinstall 実行履歴がないか
一時ディレクトリやキャッシュに不審ファイルがないか
CIランナーから通常と異なる通信先へのアクセスがないか
ビルド後にシークレット利用状況が変わっていないか

4. シークレット流出前提で洗い出す

問題のバージョンを導入した可能性が少しでもあるなら、次を洗い出します。

GitHub Actions secrets
npm token
GitHub Personal Access Token / App token
AWS / GCP / Azure のキー
Docker Hub / GHCR などのレジストリ認証情報
.env 内のAPIキー
SSH鍵
社内VPN・SaaS CLIの認証情報

この手の事故では、「入っていたが何も起きていないはず」と楽観視しないことが重要です。

万が一検知した場合、どうすべきか

もし影響バージョンの導入や実行が確認された場合、単なるバージョン差し戻しで終わらせてはいけません。
インシデントとして扱う 必要があります。

1. 端末・実行環境を隔離する

まずは影響が疑われる端末やCIランナー、ビルド環境をネットワークから切り離し、追加被害の拡大を止めます。

対象になり得る例:

開発者PC
共有ビルドサーバー
Self-hosted runner
該当期間に利用されたCI実行環境
Docker buildを行ったホスト

2. シークレットをローテーションする

次に、該当環境からアクセス可能だった認証情報をローテーションします。

優先度が高いもの:

GitHubトークン
npmトークン
クラウド認証情報
コンテナレジストリ認証情報
APIキー
SSH鍵
社内システム接続情報

ここで大事なのは、漏えいの証拠が出てから動くのではなく、漏えいした前提で動く ことです。

3. 影響調査を行う

次に、侵害が横展開していないかを確認します。

不審なGitHub操作や権限追加
不審なnpm公開やレジストリ操作
クラウド上の想定外のAPIコール
不審なデプロイ・設定変更
シークレットの利用履歴
新規作成されたトークンや認証情報

4. クリーン環境で再構築する

影響が疑われる場合、端末やランナーをそのまま使い続けるのは危険です。
必要に応じて以下を行います。

クリーンな端末の再セットアップ
CIランナーの再構築
キャッシュ破棄
クリーンな依存再取得
安全なバージョンへの固定
再発防止策を入れたうえでビルド再開

5. 社内共有と顧客影響確認

この種の事故は「開発だけの問題」では済みません。
場合によっては、以下の観点も必要です。

影響範囲の社内共有
セキュリティ担当との連携
顧客向け説明要否の確認
監査証跡の保全
再発防止計画の策定

信用に関わる事案である以上、初動の速さと説明責任の両方が求められます。

今後の再発防止として考えるべきこと

今回の件を受けて、今後は依存ライブラリの扱い方そのものを見直す必要があります。
特に重要なのは次です。

lockfile管理の徹底

依存解決結果を固定し、想定外の更新を減らします。

自動更新の即時反映を見直す

更新自体は有効ですが、公開直後の反映にはクールダウン期間を設けることも検討価値があります。

installスクリプト監査

postinstall を含む依存はより慎重に扱います。

CI権限の最小化

CIやビルド環境に過剰な権限を持たせない設計にします。

開発端末と公開権限の分離

公開・署名・デプロイ権限を持つ環境を通常の開発端末と分けることが重要です。

依存監査と可視化

SBOM、依存監査、ログ監視を継続的に行い、異常検知しやすい状態を作ります。

公開権限側の保護

2FA、最小権限、権限棚卸しを徹底し、メンテナーアカウント侵害リスクを下げます。

今後も注視が必要な理由

今回のAxiosインシデントは、一過性の話題ではありません。
むしろ今後の開発現場において、ソフトウェアサプライチェーン攻撃が標準的な脅威になっていく ことを強く示した事件です。

特に、AI支援によって開発速度が上がり、依存追加や更新が日常的に行われる時代では、従来以上に注意が必要です。
「GitHub上のコードが正しそうだから大丈夫」「人気ライブラリだから安心」という感覚は、もはや通用しません。

今回の件は、技術的な問題であると同時に、企業や開発組織の信用に直結する問題 です。
顧客から見れば、依存関係の事故も自社サービスの事故も区別されません。
だからこそ、今後も継続的に注視し、運用・監査・初動対応の成熟度を上げていく必要があります。

まとめ

AxiosはJavaScript/TypeScriptで広く使われているHTTPクライアントであり、多くのシステムの通信基盤を支える定番ライブラリです。
今回の問題は、その配布経路が侵害され、一時的に悪性パッケージが正規更新を装って配布されたという、非常に重大なサプライチェーン攻撃でした。

今やるべきことは明確です。

影響バージョンの有無を確認する
その期間に実際にインストールやビルドが走ったか確認する
端末・CI・ログを調査する
必要に応じてシークレットをローテーションする
検知時はインシデントとして扱う
今後の再発防止策を整備する

この問題は「たまたま一度起きた事件」として流してはいけません。
信用を守るための運用課題として、今後も注視し続けるべきテーマ です。

参考情報

Axios Documentation
Axios公式ポストモーテム / GitHub Issue
Microsoft Security Blog
CSA Advisory
Trend Micro / SANS / 各種セキュリティベンダー分析

Axiosのサプライチェーン攻撃について