Axios 1.15 移行ガイド2026｜互換性・破壊的変更・CVE-2026-40175対応FAQ

先に結論

• Axios 1.15.0 は「破壊的変更が主役」ではなく「セキュリティ強化が主役」のリリースである。既存の axios.get() / axios.post() の呼び出しやインターセプターの大半はそのまま動く。移行で本当につまずくのは、コードではなく 間接依存（transitive dependency）に古い Axios が残る問題 と、プロキシ正規化などの挙動変化 の2点に集約される。
• 更新の直接の理由は CVE-2026-40175（HTTP ヘッダーインジェクションを起点としたクラウドメタデータ流出の連鎖）だが、これは巷で言われるような「Axios 単体の CVSS 10.0 リモートコード実行」ではない。別の依存ライブラリで Prototype Pollution が起きていることが前提の「ガジェットチェーン型」脆弱性で、公式（GitHub/CNA）評価は CVSS 4.8（Moderate）、Red Hat 評価は 9.0（Critical）と、評価機関によってスコアが割れている（後述・出典明記）。だからこそ「怖い記事を読んで即パニック更新」ではなく、自社が実際に影響を受けるかを判定してから動くのが正しい順序になる。
• 移行の勘所は3つ。(1) npm ls axios で 全バージョンを 1.15.x 以降に揃える（間接依存の残留をつぶす）、(2) overrides／resolutions の強制指定は 副作用があるので最後の手段、(3) 1.15.0 で入った プロキシ正規化・url.parse() 廃止対応 など挙動変化をテストで確認する。
• 経営・発注の視点では、これは「HTTP クライアントの小さな更新」ではなく 「自社のソフトウェアの部品表（SBOM）を誰が管理しているか」を可視化する試金石である。外注中心の企業ほど「うちの axios は誰が上げるのか」が曖昧で、そこが最大の落とし穴になる。本記事は環境別 FAQ に加えて、外注先に何を聞けば対応済みだと確認できるかまで踏み込む。

この記事は、React / Next.js / Node.js / Nuxt などで Axios を使うプロダクトを持ち、CVE 対応や依存更新を「自社でやるか、外注先に任せるか」で迷っている情シス・開発責任者・経営者に向けた実務リファレンスである。

---

この記事を読むべき人

• 自社サービスが Axios に依存しており、1.15 系へ上げるべきか、上げた後に何が壊れるかを具体的に知りたい開発者・情シス
• セキュリティ通知（Dependabot / npm audit / ベンダー連絡）で CVE-2026-40175 を突きつけられ、本当に急ぐべき危険度なのかを判断したい情シス部長・セキュリティ担当
• システム開発を外注しており、外注先がこの CVE に対応済みかを、技術がわからなくても確認したい経営者・事業責任者
• monorepo や複数リポジトリで Axios が散らばっており、一斉に揃える段取りと完了証跡の作り方を知りたい開発リード

---

目次

1. Axios 1.15.0 で実際に変わったこと（一次情報で確認）
2. CVE-2026-40175 の正しい危険度の読み方
3. 自社が影響を受けるかの影響判定フレーム
4. 破壊的変更・非推奨の一覧と移行手順
5. 移行で最も多いトラブル3種と対処
6. 環境別の互換性（React / Next.js / Node.js / Nuxt）
7. package-lock / yarn.lock / pnpm-lock の処理
8. monorepo での依存解消と完了証跡
9. 発注前チェックリストと外注先への質問
10. なぜ経営が「部品の更新」に関与すべきか
11. FAQ（実務頻出22問）
12. GXOに相談すべきタイミング
13. 参考情報（一次・公式ソース）

---

Axios 1.15.0 で実際に変わったこと

まず、噂や二次情報ではなく Axios 公式のリリースノートと GitHub Security Advisory で確認できる事実から整理する。

Axios 1.15.0 は、大きな API 変更を含む「メジャー移行」ではなく、セキュリティ修正と挙動の締め直しを中心にしたマイナーリリースである。GitHub のリリース記載に基づくと、1.15.0 に含まれる主な変更は次のとおり（axios v1.15.0 Release）。

ここで押さえるべきは、「破壊的変更（breaking changes）」として明示された API 削除はほぼ無いという点だ。既存の呼び出しコードは基本的に動く。壊れるとすれば、(1) プロキシ正規化が厳しくなったことによる社内プロキシ経由の疎通、(2) URL 解釈の厳密化、(3) 独自インターセプターでヘッダーを直接いじっている箇所 の3か所に限られる。ここだけをテストで押さえれば、移行そのものは短時間で終わる。

なお Axios は 公式な LTS（長期サポート）版を持たず、セマンティックバージョニングで運用されている（Semantic versioning｜axios docs）。つまり「古いバージョンを固定したまま安全に使い続ける」という選択肢は公式には用意されておらず、セキュリティ修正は基本的に最新の 1.x に上げて取り込むしかない。これは後述の「なぜ更新が必要か」を経営に説明するときの重要な前提になる。

セクション要点： 1.15.0 はセキュリティ修正中心で API 破壊はほぼ無い。壊れうるのはプロキシ・URL 解釈・独自ヘッダー処理の3点だけ。Axios に LTS は無く、修正取り込み＝最新 1.x への追随が原則。

---

CVE-2026-40175 の正しい危険度の読み方

ここが本記事で最も重要なパートである。多くの記事が 「Axios に CVSS 10.0 のリモートコード実行脆弱性」 と煽っているが、一次情報を読むとその表現は不正確だ。恐怖で発注判断を歪めないために、事実を分解する。

何が起きる脆弱性なのか

NVD の記載（2026年4月10日公開）と GitHub Security Advisory（GHSA-fvcv-3m26-pcqx） によると、CVE-2026-40175 は以下の連鎖（ガジェットチェーン）で成立する。

1. 前提：スタック内の 別の ライブラリ（例：qs, minimist, ini, body-parser など）に Prototype Pollution の脆弱性があり、攻撃者が Object.prototype を汚染できる。
2. Axios 側の欠陥：Axios は設定（config）をマージする際、汚染されたプロパティをリクエストヘッダーに引き継ぐ。1.15.0 より前は、その値に含まれる CRLF（\r\n）を検証していなかった。
3. 結果：CRLF を含むヘッダー値が注入され、HTTP リクエストが不正に再構築される（HTTP リクエストスマグリング／SSRF）。これを悪用すると、クラウドのメタデータエンドポイント（AWS IMDSv2 など）に到達して認証情報を抜き取ることが理論上可能になる。

つまり、Axios 単体では発火しない。「Axios がプロトタイプ汚染を起こす」のでも「Axios だけで RCE する」のでもなく、汚染源となる別の脆弱な依存が同居していて初めて成立する、条件付きの脆弱性である。関連 CWE は CWE-113（CRLF の不適切な中和）、CWE-444（HTTP リクエストスマグリング）、CWE-918（SSRF）、CWE-915（動的に決まるオブジェクト属性の不適切な変更）と記録されている。

スコアは評価機関で割れている

危険度の数字も一枚岩ではない。同じ NVD ページ上で、評価元によってスコアが大きく異なる。

同じ脆弱性で 4.8 と 9.0 が併存している状態だ。共通しているのは 攻撃複雑度が High（AC:H）であること――すなわち「汚染源の依存が別途存在し、かつ攻撃者がそれを操作できる」という条件が揃わないと成立しない、という評価である。したがって、「10.0 の RCE」という表現はどの一次評価とも一致しない。二次情報のブログには「CVSS 10.0」「Axios の Prototype Pollution → RCE」と書くものがあるが、これは正確でない可能性が高いと考えるべきだ。

（補足：修正版のバージョン表記も一次ソース間で表記揺れがある。1.x 系は 1.15.0 で修正、0.x 系は後方移植版が出ているが、advisory では 0.31.0、一部記載では 0.3.1 と食い違う。0.x 系を使っている場合は自分の環境で最新の 0.x 修正版を確認すること。）

GXO の見方：怖がり方を間違えない

「割れているスコア」を実務でどう扱うか。GXO は次のように判断軸を分ける。

• 上限で備え、実態で優先度を決める。最悪ケース（Red Hat の 9.0）を想定して対応計画は立てるが、着手の優先順位は「自社が実際に影響を受けるか」で決める。全依存を一斉に止めて緊急更新するか、通常の定例更新に乗せるかは、次章の影響判定で分かれる。
• 数字を鵜呑みにしない情報リテラシーそのものが防御力になる。ベンダーや記事が「CVSS 10.0」と言ってきたら、それは一次情報を確認していないサインかもしれない。出典（NVD / GitHub Advisory）を必ず突き合わせる。

セクション要点： CVE-2026-40175 は「別の依存の Prototype Pollution」が前提のガジェットチェーン。攻撃複雑度は High、公式スコアは 4.8〜9.0 で割れ、「10.0 の RCE」は不正確。最悪ケースで備え、実態で優先度を決める。

---

自社が影響を受けるかの影響判定フレーム

セキュリティ通知は「読むだけ」では防御にならない。自社資産・影響判定・対応期限・経営報告に変換して初めて意味を持つ。CVE-2026-40175 について、更新の緊急度を上げるべきか下げるべきかを、次の5問で仕分けられる。

この5問を通すと、「axios は使っているが、外部入力をヘッダーにマージしておらず、汚染源の依存も無い」 ケースでは、緊急のサービス停止更新までは不要で、定例の依存更新サイクルで 1.15 系に上げれば十分と判断できることが多い。逆に 「外部入力を扱い、クラウド上で動き、汚染源候補の依存が同居」 なら最優先で塞ぐ。この仕分けを飛ばして全社一斉に手を止めると、コストだけかかって費用対効果が説明できなくなる。ここが最初の判断ミスの分岐点である。

このような 「自社条件に落とした影響判定」 は、公開情報だけでは完結しない。現行システムの依存関係・業務フロー・データの流れを棚卸ししたうえで初めて確度が出る。ここを外部の目で早く整理したい場合は、移行前の第三者アセスメントで影響範囲を切り分けるところから始めると、緊急対応と定例更新の線引きがぶれない。

---

破壊的変更・非推奨の一覧と移行手順

「1.15 系への移行」といっても、多くのプロジェクトは 1.0 以降のどこかから上げてくる。ここでは 1.15.0 固有の変更 と、1.x を跨いで上げる際に踏みうる非推奨・挙動変化 を分けて示す。

1.15.0 固有で確認すべき点

• プロキシ正規化の変更：no_proxy の正規化が厳格化された。社内プロキシ・許可リストに依存する構成は、更新後に対象ホストへ正しく直結／迂回できるか疎通テストを行う。
• url.parse() 廃止対応：内部での URL 解釈が変わったため、末尾スラッシュや不正形式の URL を渡していると結果が変わりうる。URL を動的生成している箇所は要確認。
• ヘッダー値の CRLF 検証追加：これが CVE 修正の本体。ヘッダー値に改行を意図的に入れて特殊制御していた（本来やってはいけない）実装があれば、拒否されるようになる。

1.x を跨いで上げる際に踏みやすい非推奨（二次情報を含む・要自環境検証）

• URL パラメータのエンコード仕様：1.x で params がデフォルトでパーセントエンコードされる仕様変更が入っている。古い挙動を前提にクエリを組んでいると差異が出る。
• リクエストインターセプターの型：TypeScript では InternalAxiosRequestConfig で config を型付けする形に整理されている。AxiosRequestConfig のまま書いていると型エラーが出うる。
• @types/axios の廃止：型定義は本体に同梱される。別途 @types/axios を入れていると衝突・警告の原因になるため削除する。

これらは Axios のバージョン間で段階的に入った変更で、一部は二次情報（コミュニティ・解説記事）に基づくため、必ず自環境の tsc --noEmit とテストで裏取りすること。

推奨する移行手順（段階アップグレード）

Axios には LTS が無いため、大きく飛ばすほどリスクが上がる。公式・コミュニティが共通して推奨するのは 「マイナーを一段ずつ上げ、各段でテストを回す」段階アップグレードである。

1. 現在のバージョンを npm ls axios で確定（直接・間接すべて）。
2. パッチ／マイナー単位で一段上げ、tsc --noEmit と単体・結合テストを実行。
3. プロキシ・URL 生成・独自ヘッダーの3点を重点的に手動確認。
4. 1.15.0 以降まで到達したら、npm audit で当該 CVE が消えたことを確認。
5. 完了証跡（更新前後の npm ls axios と audit 結果）を保存。

セクション要点： API 破壊はほぼ無いが、プロキシ・URL・独自ヘッダー・params エンコード・TS 型・@types/axios の6点は挙動が変わりうる。飛ばさず一段ずつ上げ、各段でテストと audit を回す。

---

移行で最も多いトラブル3種と対処

現場で発生するトラブルの大半は、コードそのものではなく 依存グラフ で起きる。頻度順に3つ挙げる。

トラブル1：間接依存に古い Axios が残る（最頻）

npm ls axios を叩くと 1.15.x と古いバージョンが混在する。あなたの package.json は最新でも、別のライブラリが古い Axios に依存しているためだ。これが移行トラブルの約8割を占める体感。

対処の基本は、まずロックファイルと node_modules を作り直すこと。

rm -rf package-lock.json node_modules
npm install
npm ls axios   # すべて 1.15.x 以降であることを確認

それでも古いバージョンが残るなら、overrides（npm 8.3 以降）で強制する。

"overrides": {
  "axios": "^1.15.0"
}

ただし overrides は最後の手段である。古い Axios に依存しているライブラリが、実は新しい Axios では動かない設計の場合、強制すると そのライブラリ側が壊れる。強制指定した後は、依存元ライブラリの動作を必ずテストする。理想は「依存元ライブラリ自体を新しくして、自然に新 Axios を引く」状態に持っていくことだ。

トラブル2：TypeScript の型エラー

型定義の整理により、厳密な型チェック環境で警告が出る。対処は、(1) @types/axios を入れていれば削除、(2) tsc --noEmit で全体を再チェック、(3) インターセプターの config は InternalAxiosRequestConfig を使う、(4) どうしても収束しなければ局所的に明示キャスト。型エラーは「壊れている」のではなく「型が厳しくなった」だけのことが多く、慌てて any で潰すと後で別の不具合を隠すので避ける。

トラブル3：独自インターセプターの挙動変化

CVE 修正でヘッダー処理が厳格化された結果、response.headers を直接書き換えている独自インターセプターが想定外の動きをすることがある。対処は、(1) ヘッダーを直接改変している箇所を洗い出す、(2) Object.assign によるマージをスプレッド構文に置き換える、(3) テスト環境でインターセプターの入出力を確認。特に ヘッダー値に改行を混ぜて制御していた実装は、そもそも CVE の温床なので、この機会に設計から直す。

セクション要点： 8割は間接依存の残留。まずロック作り直し、overrides は副作用前提の最後の手段。型エラーは「厳格化」、独自ヘッダー処理は「設計を直す好機」と捉える。

---

環境別の互換性

主要フレームワークでの実務上の注意を整理する。基本的にはどの環境でも 1.15 系は動くが、確認すべき箇所が環境ごとに違う。

React（CRA / Vite）

影響は小さい。多くは直接依存のみで、npm ls axios を揃えれば済む。注意点は MSW（Mock Service Worker）併用時のインターセプター動作。MSW が古いと、ヘッダー処理厳格化と噛み合わずテストが落ちることがあるため、MSW も最新化する。

Next.js

App Router / Pages Router いずれでも動作する。SSR やサーバー側（API Routes / Route Handlers）で Axios を使っている場合、サーバー実行時の挙動確認が要。特にプロキシ経由で外部 API を叩く構成は、プロキシ正規化変更の影響を受けやすい。古い Next.js（12 系など）は EoL のため、Axios 更新と同時に Next.js 本体の更新計画も立てるのが望ましい。

Node.js（Express / Fastify / NestJS）

Node.js 18 以降で動作。18 未満は EoL でそもそも非推奨。NestJS の HttpService（@nestjs/axios）経由でも動くが、@nestjs/axios のバージョンが内部で古い Axios をピン留めしていないかを npm ls axios で必ず確認する。

Nuxt / Vue.js

Nuxt 3 では @nuxtjs/axios は非推奨で、公式は $fetch への移行を推奨している。Axios を使い続ける場合は直接依存として管理する。Nuxt 2 系はモジュールの最新版で 1.15 系に追随できるが、Nuxt 2 自体が保守終息に向かっているため、更新はモダナイゼーション計画とセットで考える。

React Native / Electron

React Native は Axios 自体は動くが、ネイティブ通信モジュールとの組み合わせで稀に問題が出る。timeout を明示設定しておくとトラブルを切り分けやすい。Electron は Main 側と Renderer 側で別々の Axios を持つことがあり、片方だけ更新すると脆弱性が残る。両方を揃える。

セクション要点： どの環境も動くが確認箇所が違う。React は MSW、Next はサーバー実行とプロキシ、NestJS/Nuxt は内部ピン留め、Electron は Main/Renderer 二重更新に注意。

---

Lockファイル処理の実務

パッケージマネージャーごとに、間接依存を強制する記法が異なる。**強制指定は「効くが副作用がある」**という前提で使う。

npm

rm -rf package-lock.json node_modules
npm install
npm ls axios

残る場合は package.json に overrides（npm 8.3 以降）。

"overrides": { "axios": "^1.15.0" }

yarn

rm -rf yarn.lock node_modules
yarn install
yarn why axios

残る場合は resolutions。

"resolutions": { "axios": "^1.15.0" }

pnpm

rm -rf pnpm-lock.yaml node_modules
pnpm install
pnpm list axios --depth Infinity

残る場合は pnpm.overrides。

"pnpm": { "overrides": { "axios": "^1.15.0" } }

いずれの記法でも、強制後は 依存元ライブラリの回帰テスト を必ず行う。ロックファイルを作り直すと Axios 以外の依存も動く可能性があるため、差分（git diff のロックファイル）を確認し、意図しない大量アップグレードが混ざっていないかをレビューすること。ここを見ずにマージして別の不具合を出すのは、移行時の典型的な失敗である。

セクション要点： npm=overrides / yarn=resolutions / pnpm=pnpm.overrides。強制は最後の手段で、実行後はロックファイル差分レビューと依存元テストが必須。

---

monorepo での依存解消と完了証跡

Turborepo / Nx / Lerna / pnpm workspaces などの monorepo では、各パッケージが独自に Axios を持つため、**「一部だけ直って一部が残る」**状態になりやすい。対応の型は次のとおり。

1. ルートで一元管理：ルート package.json の overrides（または各 workspace の版揃え）で全体を 1.15 系に寄せる。
2. 直接依存の版を統一：apps/* packages/* の各 package.json で Axios の版指定を揃える。理想は「ルートで一括＋各パッケージは範囲指定」で二重管理を避ける。
3. CI に監査を組み込む：漏れを人力で追わず、CI で自動検知する。

# .github/workflows/audit.yml（例）
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm audit --audit-level=high

そして CVE 対応で最も忘れられがちなのが 「完了証跡」 である。経営報告や取引先へのセキュリティ回答で「対応済み」と言い切るには、口頭ではなく 記録が要る。最低限、次を保存しておく。

• 更新前後の npm ls axios（全バージョンが 1.15 系に揃った証跡）
• npm audit（当該 CVE が消えた証跡）
• 対応日・対象リポジトリ一覧・担当者
• 可能なら SBOM（ソフトウェア部品表）を出力し、依存の棚卸し結果として保管

複数リポジトリ・複数サービスをまたぐ一斉更新は、この「揃える段取り」と「証跡の残し方」で品質が決まる。ここを仕組み化したい場合は、レガシー刷新・システム移行の進め方の考え方をベースに、依存の棚卸しから CI 監査、証跡管理までを一続きの運用として設計するのが有効だ。

セクション要点： monorepo は「一部だけ直る」を防ぐのが肝。ルート一元管理＋CI 監査で漏れを潰し、npm ls / audit / SBOM を完了証跡として残す。

---

発注前チェックリストと外注先への質問

ここからは、開発を外注している経営者・事業責任者向けである。「axios を上げてください」と一言で頼めば済む話ではない。以下を確認・依頼できると、対応の質とコストのブレが大きく変わる。

発注前・依頼前チェックリスト

• 自社サービスが Axios に依存しているか、依存の有無自体を外注先に確認したか
• 直接依存だけでなく 間接依存も 1.15 系に揃えることを依頼範囲に明記したか
• 対象が 1リポジトリか、複数リポジトリ／monorepo かを洗い出したか
• 更新後の **回帰テスト（プロキシ・URL 生成・独自ヘッダー）**まで依頼に含めたか
• overrides／resolutions を使う場合、依存元ライブラリが壊れないことの確認を依頼したか
• **完了証跡（npm ls / audit / 対応日・対象一覧）**の提出を成果物条件にしたか
• この CVE の危険度を、自社の実行環境（クラウド／外部入力の有無）に照らして判定してもらったか
• 今回だけの単発対応か、今後の依存更新を継続的に回す運用まで含めるかを決めたか

外注先に投げるべき質問（技術がわからなくても効く）

• 「うちの製品で npm ls axios を叩くと、いま何バージョンが混在していますか？」――即答できるかで、依存を把握しているかがわかる。
• 「今回の CVE-2026-40175 は、うちの環境で実際に悪用されうる条件が揃っていますか？（外部入力をヘッダーに載せているか／汚染源の依存があるか）」――「とりあえず上げます」しか返らないなら、影響判定をしていない。
• 「対応の 完了証跡はどんな形で出してもらえますか？」――取引先や監査に出せる形式かを確認。
• 「依存の更新は今後どう回りますか？（Dependabot / Renovate の有無、週次・月次の運用）」――単発で終わらせず、次の CVE に備える体制があるか。

見積もりの読み方

「axios 一斉更新」の見積もりで、金額の妥当性は 工数の内訳に現れる。健全な見積もりは、①依存の棚卸し（npm ls）、②更新作業、③回帰テスト、④証跡作成、⑤（複数リポジトリなら）横展開――が分解されている。逆に 「更新作業一式」だけで金額が出てくる見積もりは、テストと証跡が抜けている可能性が高い。安く見えても、後で「動作確認は別途」と追加費用が発生しがちだ。ここを事前に分解して確認するだけで、追加費用と手戻りの多くは防げる。

自社の依存状況が不明なまま見積もりだけ取ると比較のしようがない。まずは現状を第三者の目で整理したい場合、システム移行・再構築を相談する前段として、影響範囲と工数の粒度をそろえておくと、複数社の見積もりを同じ土俵で比較できる。

セクション要点： 外注では「間接依存まで／回帰テストまで／完了証跡まで」を依頼範囲に明記。見積もりは工数の内訳で妥当性を測り、「一式」表記の抜けを警戒する。

---

なぜ経営が「部品の更新」に関与すべきか

Axios は自社で書いたコードではない。だから「開発者が勝手に上げればいい」と思われがちだが、CVE-2026-40175 のような事案は、経営が関与すべき問題を3つ露わにする。

第一に、「自社ソフトの部品表を誰が管理しているか」問題。現代の Web システムは、自社コードよりも遥かに大量のオープンソース部品（依存ライブラリ）で構成される。その一つに脆弱性が出るたびに、誰かが気づき、影響を判定し、更新し、証跡を残す必要がある。外注中心の企業では、この責任範囲が契約書に書かれていないことが多く、「誰も見ていない」状態が生まれる。CVE はその穴を可視化する。

第二に、「単発対応か、継続運用か」の投資判断。今回 axios を上げても、来月は別のライブラリに CVE が出る。Dependabot / Renovate による自動 PR と、週次・月次のレビュー運用を仕組みにするかどうかは、開発者個人ではなく経営の投資判断である。仕組みが無ければ、脆弱性対応は毎回「火消し」になり、コストも読めない。

第三に、セキュリティ通知を経営言語に翻訳できるか。「CVSS がいくつ」ではなく、「自社のどのサービスの、どのデータに、どの期限までに対応が要るか」を1枚で説明できる状態を作ること。これは月次のセキュリティ運用として設計できる。レガシーな構成のまま放置された依存関係は、更新のたびに連鎖的に壊れやすく、モダナイゼーション（構成の作り直し）とセットで考えるべき局面も多い。

要するに、Axios の一件は「HTTP クライアントのバージョン上げ」ではなく、自社の技術資産をどう継続管理するかという経営テーマの入口である。ここを外注先任せにせず、判断軸と体制を持てるかが、次の失敗を防ぐ分かれ目になる。

---

FAQ（実務頻出22問）

Q1. npm audit fix で解決しないのですが？

間接依存の制約で自動修正できないケース。overrides（npm）／resolutions（yarn）／pnpm.overrides で強制指定する。ただし依存元ライブラリが壊れないかを更新後にテストすること。

Q2. CI の npm audit 警告を運用でどう扱う？

--audit-level=high で High 以上に絞り、--omit=dev で本番に無関係な devDependencies を除外できる。ただし恒久的な完全無視は非推奨。除外するなら理由を記録に残す。

Q3. Nuxt 2 で @nuxtjs/axios の更新が通りません。

@nuxtjs/axios のメジャー移行（5.x→6.x など）が同時に必要になることがある。モジュール側のドキュメントに従い段階的に。Nuxt 3 なら $fetch への移行を検討。

Q4. Jest / Storybook で Axios のモックが効かなくなった。

ヘッダー処理厳格化の影響。axios-mock-adapter や MSW を最新化する。MSW は 2.x への更新が要るケースがある。

Q5. Webpack で「prototype 関連」の警告が出るように。

CVE 対策に伴う実装変更の一環で、動作自体は問題ないことが多い。まずビルドとテストが緑かを確認し、警告内容の出典を切り分ける。

Q6. React Native の iOS で通信エラーが増えた。

timeout のデフォルト挙動やネイティブモジュールとの相性の可能性。timeout を明示設定し、失敗リクエストのログで切り分ける。

Q7. Next.js 12 でも 1.15 に上げられますか？

上げられる。ただし Next.js 12 は EoL。Axios 更新と同時に Next.js 本体の更新計画も立てるのが安全。

Q8. MSW のテストが落ちる。

MSW 2.x への更新が必要なケース。Axios のヘッダー／レスポンス処理厳格化に MSW 側を合わせる。

Q9. Electron で動作が不安定。

Main 側と Renderer 側で別々の Axios を持っている可能性。npm ls axios で両方を確認し、双方を 1.15 系に揃える。

Q10. SvelteKit で型エラー。

@sveltejs/kit の最新化と TypeScript の strict 設定の組み合わせで調整。インターセプターは InternalAxiosRequestConfig を使う。

Q11. overrides を書いたのに効かない。

npm 8.3 未満は overrides 非対応。npm --version を確認し npm 9 系以降へ。yarn は resolutions、pnpm は pnpm.overrides と記法が違う点にも注意。

Q12. @types/axios を消したら別の型エラーが出た。

Axios 本体の型に切り替わったことで、これまで曖昧に通っていた箇所が顕在化しただけのことが多い。tsc --noEmit の指摘に沿って型を直す。any で潰さない。

Q13. 0.x 系（0.27 など）を使っています。どうすべき？

0.x 系にも後方移植の修正版が出ている。ただし一次ソース間でバージョン表記に揺れ（0.31.0 / 0.3.1）があるため、自環境で最新の 0.x 修正版を確認する。可能なら 1.x への移行計画を別途立てる。

Q14. CI の Docker イメージで古い Node.js が使われている。

node:18-alpine など 18 以降のイメージへ更新。古い Node.js は EoL で、そもそも Axios 以外のリスクも抱える。

Q15. 社内プロキシ経由で通信が変わった。

1.15.0 のプロキシ正規化（no_proxy）変更の影響が濃厚。許可ホストへの直結／迂回が意図どおりかを疎通テストで確認する。

Q16. CDN 配信で Axios を読み込んでいます。

latest 指定は避け、1.15.x にバージョン固定する。自動アップデートで予期せず壊れるのを防ぐ。

Q17. Deno / Bun で 1.15 は動きますか？

1.15.0 で Deno / Bun のサポートとドキュメントが追記された（リリースノート）。ただしコミュニティにはネイティブ fetch の利用を勧める声もある。

Q18. Cypress の XHR スタブが機能しなくなった。

Cypress 13 以降を推奨。古い Cypress はインターセプターの挙動変化に追従していないことがある。

Q19. 自前で Prototype Pollution 対策を入れています。もう不要？

Axios 側の CRLF 検証は 1.15.0 で標準化された。ただし CVE の汚染源は「別の依存」なので、汚染源側（qs 等）の対策は依然として必要。Axios を上げれば全部安全、ではない点に注意。

Q20. params のクエリ文字列が以前と変わった。

1.x で params がデフォルトでパーセントエンコードされる仕様。古い挙動前提のコードは差異が出る。カスタム paramsSerializer の要否を確認。

Q21. 独自 fork の Axios を使っています。

本家の CVE 修正 diff を fork に同等適用する必要がある。fork を保守し続けるコストと、本家 1.15 系へ戻すコストを比較して判断する。

Q22. この後また別の CVE が出たらどうする？

Dependabot / Renovate で自動 PR を有効化し、週次または月次でレビューする運用を作る。単発対応ではなく、継続運用として仕組み化するのが本質的な解。

---

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、記事で一般論を把握したうえで、早めに第三者へ相談したほうが安全だ。

• 自社が Axios に依存しているか、依存の有無や影響範囲がそもそも把握できていない
• 複数リポジトリ・複数サービスに散らばっており、一斉更新の段取りと完了証跡の作り方が分からない
• 外注先が対応済みと言うが、その内容が妥当か第三者視点で確認したい
• CVE 対応が毎回「火消し」になっていて、継続的に依存を管理する運用に切り替えたい
• 依存が古い構成のまま連鎖的に壊れやすく、レガシー刷新・モダナイゼーションとセットで整理したい
• 稟議で費用対効果・リスク・ロードマップを経営に1枚で説明する必要がある

GXO は、脆弱性そのものへの一次対応にとどまらず、依存の棚卸し、影響判定、更新運用の仕組み化、そして構成の作り直しまでを一続きで支援する。まずは自社条件に落とした整理から始めたい場合は、移行前の第三者診断で現状と優先度を切り分けるところが入口になる。

Axios 移行・依存更新の進め方を無料相談する

※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。オンライン対応可。

---

ペルソナ適合チェック

• 対象読者：Axios 依存のプロダクトを持つ成長中小企業の経営者・事業責任者・情シス。社内に十分な IT 判断力が無く、外注の妥当性を確かめたい層。
• 失敗トリガー：「CVSS 10.0 の RCE」という煽りを鵜呑みにして過剰対応する／逆に間接依存の残留を見落として無対応になる／外注先の対応範囲を明記せず追加費用と手戻りを招く。
• 診断価値：影響判定の5問フレーム、破壊的変更の限定リスト、外注先への質問集、見積もりの内訳の読み方、完了証跡の作り方。
• GXO 着地導線：影響範囲の第三者アセスメント → 一斉更新・運用仕組み化 → レガシー刷新まで。

---

参考情報

一次・公式ソース（本文の技術・脆弱性の記述はこれらで裏取り。バージョン表記やスコアは一次ソース間で揺れがある箇所を本文で明示した）。

• axios v1.15.0 Release Notes（GitHub）
• axios CHANGELOG（v1.x）
• GitHub Security Advisory｜GHSA-fvcv-3m26-pcqx（CVE-2026-40175）
• NVD｜CVE-2026-40175 Detail
• Semantic versioning｜axios 公式ドキュメント

公的・二次情報（一般的なセキュリティ運用の根拠として）。

• IPA 情報セキュリティ
• JPCERT/CC
• OWASP Top 10