axios 脆弱性対応ガイド 2026：影響確認・バージョンアップ・代替手段の判断まで

2026年4月1日

npm audit の警告を見て「とりあえず後回し」にしていませんか。本記事は、axios を本番利用している開発者・セキュリティ担当者を対象に、既知の脆弱性の実態・影響範囲の確認手順・バージョンアップ時の注意点・fetch への移行判断基準までを実務視点で整理します。検証・運用の現場で実際に直面した問題を踏まえて解説するため、「警告は出ているが何をすればいいかわからない」という状態を解消することを目標とします。

axios の主要脆弱性と対処バージョン比較

CVE ID	深刻度	影響バージョン	内容	対処バージョン
CVE-2023-45857	High	0.8.1〜1.5.1	CSRF：XSRF-TOKEN がクロスオリジンに漏洩	1.6.0 以上
CVE-2024-39338	Medium	1.0.0〜1.7.3	SSRF：Node.js 環境で相対 URL がバイパス	1.7.4 以上
CVE-2020-28168	Medium	〜0.21.0	プロトタイプ汚染：任意プロパティの書き換え	0.21.1 以上

それぞれの詳細は後述します。現在使用中のバージョンを確認し、該当する CVE がないかまず照合してください。

検証環境

OS : macOS Sequoia 15.3
Node.js : 20.18.0
TypeScript : 5.4.5
主要パッケージ :
- axios : 1.7.9
- vite : 5.4.0
検証日 : 2026年03月31日

axios の脆弱性が問題になる技術的背景

axios は 2014 年から広く使われてきた HTTP クライアントライブラリです。ブラウザと Node.js の両環境で動作し、Promise ベースのインターフェースを提供します。週あたりのダウンロード数は長年にわたって数億件を超えており、実質的に「デファクトスタンダード」として定着してきました。

しかしその普及度ゆえに、脆弱性が発見された際の影響範囲は非常に大きくなります。また、axios は直接依存だけでなく、他のパッケージが間接的に依存していることも多く、自分のコードで使っていなくても npm audit に登場するケースがあります。

以下の図は、axios がリクエストを処理する際の主要フローと、脆弱性が発生しやすい箇所を示しています。

mermaidflowchart LR
  A["アプリケーション"] --> B["axios インスタンス"]
  B --> C["インターセプター処理"]
  C --> D["リクエスト設定の解決"]
  D --> E{"環境判定"}
  E -- ブラウザ --> F["XMLHttpRequest"]
  E -- Node.js --> G["http/https モジュール"]
  F --> H["レスポンス"]
  G --> H
  D -. "CVE-2023-45857<br/>XSRF-TOKEN 付与" .-> F
  D -. "CVE-2024-39338<br/>相対URL解決" .-> G

インターセプターとリクエスト設定の解決フェーズで問題が起きやすい構造になっています。ブラウザ向けとNode.js向けの分岐があるため、それぞれ異なる攻撃ベクターが存在します。

現場で起きた課題：放置するとどうなるか

CVE-2023-45857 が引き起こす CSRF リスク

CSRF（Cross-Site Request Forgery）とは、ユーザーが意図しないリクエストを攻撃者が別サイトから送信させる攻撃手法です。

CVE-2023-45857 は、axios が withCredentials: true 設定時に XSRF-TOKEN ヘッダーをオリジンをまたいで送信してしまう問題です。本来 XSRF-TOKEN は同一オリジンのリクエストにのみ付与されるべきですが、この脆弱性が存在するバージョンでは第三者サイトへのリクエストにもトークンが漏洩します。

実際に試したところ、以下の条件が揃うと攻撃が成立することを確認しました。

サーバーが Cookie ベースの認証を採用している
フロントエンドが withCredentials: true でリクエストを送っている
axios のバージョンが 1.5.1 以下

この条件は、BFF（Backend for Frontend）構成を採用している SPA では珍しくなく、多くのプロダクトが対象になりえました。

CVE-2024-39338 が引き起こす SSRF リスク

SSRF（Server-Side Request Forgery）とは、サーバーが意図しない内部リソースや外部ホストへリクエストを送らされる攻撃手法です。

CVE-2024-39338 は、Node.js 環境で axios が相対 URL を解決する際、file:// スキームを含む URL が意図せず処理されてしまう問題です。ユーザー入力を URL の一部として受け取り axios で fetch するような実装では、内部ネットワークへのプロキシとして悪用されるリスクがあります。

業務で問題になったケースとして、以下のパターンがありました。

ユーザーが指定した外部サービスの URL を Node.js サーバーが中継するマイクロサービス構成
http://localhost:9200 （Elasticsearch）など内部サービスへのアクセスが通ってしまう

npm audit の警告を無視し続けた結果

npm audit は脆弱性を検出しますが、警告を無視し続けると以下の問題が起きます。

つまずきやすい点：npm audit の出力は severity が高いものと低いものが混在します。「どれを優先すべきか」の基準がないと、全件を後回しにしやすくなります。

CI が audit チェックを強制していない場合、警告が蓄積する
間接依存の脆弱性は package-lock.json を見ないと気づきにくい
バージョンが離れすぎると、一度のアップグレードで破壊的変更が複数重なる

実際に約1年放置したプロジェクトでは、axios の major バージョンをまたぐアップグレードが必要になり、インターセプターの書き直しに数時間を要しました。

解決策と判断：アップグレード・設定変更・移行の選択

選択肢の整理

対応策は大きく3つです。

axios をアップグレードする（最も現実的）
ワークアラウンドとして設定を変更する（一時対応）
fetch / ky に移行する（抜本的）

採用しなかった「設定だけで回避」という案については、CVE-2023-45857 の場合 xsrfCookieName や xsrfHeaderName を空にすることで症状を回避できますが、本質的な修正ではなく他のリクエスト設定と干渉するリスクがあるため、長期的な解決策には採用しませんでした。

アップグレードの判断基準

以下の条件を満たす場合は、まずアップグレードを選択します。

axios のカスタムインターセプターを多用していない
プロジェクトの axios 利用箇所が20ファイル未満
Node.js 18以上 / ブラウザモダン環境のみを対象としている

逆に以下の場合は fetch/ky への移行を検討します。

axios 固有の機能（自動変換・インスタンス管理）をほとんど使っていない
バンドルサイズを削減したい（axios は約14KB gzip）
Node.js 環境のみで使用している（Node 18 以降は fetch が標準搭載）

具体的な対応手順

Step 1：現在の axios バージョンと脆弱性を確認する

まず現状を把握します。

bash# インストール済みバージョンの確認
npm list axios

# 脆弱性の確認
npm audit --audit-level=moderate

間接依存として axios が含まれている場合は以下で確認します。

bashnpm list axios --all

Step 2：package.json でバージョンを更新する

直接依存の場合はそのままアップグレードします。

bashnpm install axios@latest

間接依存（他パッケージが依存している）の場合は overrides を使います。

json{
  "overrides": {
    "axios": "^1.7.9"
  }
}

つまずきやすい点：overrides は npm 8.3 以上で使用可能です。yarn の場合は resolutions フィールドを使います。設定後は npm install を再実行してください。

Step 3：0.x → 1.x のマイグレーション時の注意点

axios 0.x から 1.x へのアップグレードでは、以下の変更が影響することがあります。

typescript// 0.x では AxiosRequestConfig を直接インポートできた
import { AxiosRequestConfig } from 'axios';

// 1.x では InternalAxiosRequestConfig が追加されている
// インターセプター内では InternalAxiosRequestConfig を使う
import { InternalAxiosRequestConfig } from 'axios';

const instance = axios.create();
instance.interceptors.request.use(
  (config: InternalAxiosRequestConfig) => {
    config.headers['X-Custom-Header'] = 'value';
    return config;
  }
);

検証の結果、インターセプター内で AxiosRequestConfig を型として使っていた箇所がコンパイルエラーになることを確認しました。InternalAxiosRequestConfig への変更が必要です。

Step 4：fetch への移行例（axios を使っていない場合）

もし axios の特定機能に依存していないなら、fetch への移行はシンプルです。

typescript// axios 版
const { data } = await axios.get<User>('/api/users/1');

// fetch 版（同等の処理）
const res = await fetch('/api/users/1');
if (!res.ok) throw new Error(`HTTP error: ${res.status}`);
const data: User = await res.json();

エラーハンドリングの方式が異なる点に注意が必要です。axios は 4xx/5xx で自動的に例外を throw しますが、fetch は res.ok を自分でチェックする必要があります。

axios 脆弱性対策の比較まとめ

対策方法の詳細比較

対策方法	効果	工数	向いているケース	向かないケース
axios アップグレード	根本解決	低〜中	依存が多いプロジェクト	major バージョン差が大きい場合
overrides / resolutions	間接依存を強制更新	低	直接触れないパッケージ経由の脆弱性	バージョン競合が起きやすい環境
設定ワークアラウンド	一時的な症状回避	低	緊急対応・テスト前の暫定処置	長期運用・根本解決が必要な場面
fetch / ky への移行	axios 依存ごと排除	高	新規・リファクタリング中のプロジェクト	axios 固有機能を多用している場合