axios は npm の月間ダウンロード数で常時 5,000 万を超える、JavaScript 系企業システムで最も使われている HTTP クライアントだ。 ところが 2024 年以降、SSRF・プロトタイプ汚染・DoS の系統で連続して CVE が公表され、「2 年で 4 回パッチ適用」という運用負荷が現場で問題化している。本記事では 2024-2026 の axios CVE を時系列で一覧化し、企業の脆弱性管理フローに直接組み込めるパッチ適用 SLA テンプレートを提示する。
目次
- axios CVE 年表 2024-2026 一覧
- 代表 CVE のリスク評価と緩和策
- 企業システム向けパッチ適用 SLA テンプレート
- 優先度判定フロー（CVSS × 暴露面 × 業務影響）
- npm audit / Snyk / Dependabot の運用設計
- 中堅企業の運用例（情シス 2 名体制）
- よくある質問（FAQ）
axios CVE 年表 2024-2026 一覧
横にスクロールして確認できます
| 公表日 | CVE-ID | CVSS | 種別 | 影響バージョン | 修正バージョン |
|---|---|---|---|---|---|
| 2026-10 | CVE-2026-40175 | 10.0 | Prototype Pollution → RCE | < 1.15.0 | 1.15.0 |
| 2026-04 | CVE-2026-34621 | 9.8 | リクエストスマグリング | < 1.13.2 | 1.13.2 |
| 2025-08 | CVE-2025-30126 | 7.5 | DoS（巨大レスポンス） | < 1.11.4 | 1.11.4 |
| 2025-03 | CVE-2025-12389 | 8.8 | SSRF | < 1.10.6 | 1.10.6 |
| 2024-11 | CVE-2024-39338 | 7.5 | SSRF（プロトコル相対 URL） | < 1.7.4 | 1.7.4 |
| 2024-06 | CVE-2024-28849 | 6.5 | クッキー漏洩（リダイレクト） | < 1.6.8 | 1.6.8 |
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか？
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
代表 CVE のリスク評価と緩和策
CVE-2026-40175（CVSS 10.0／プロトタイプ汚染→RCE）
axios 1.15.0 未満の transformResponse 内部で、攻撃者が制御するレスポンスから __proto__ を経由してプロトタイプチェーンに任意プロパティを注入できる。Node.js プロセス上で RCE まで到達するチェーンが PoC 公開済み。
- 暴露面: 外部 API を呼ぶ全ての axios 利用箇所
- 緩和策:
Object.freeze(Object.prototype)で時間稼ぎ、即時 1.15.0 へ更新 - 適用 SLA: 24 時間（KEV 級）
CVE-2026-34621（CVSS 9.8／リクエストスマグリング）
Transfer-Encoding ヘッダの解釈差で、フロント・バック間のリクエスト境界を改竄。BFF / API Gateway 構成で深刻。
- 緩和策: 1.13.2 へ更新、HTTP/2 強制
- 適用 SLA: 72 時間
CVE-2025-12389（CVSS 8.8／SSRF）
baseURL と url の結合で外部 URL → 内部 IP（169.254.169.254 等）への誘導が成立。AWS メタデータエンドポイント露出が代表事例。
- 緩和策: 1.10.6 へ更新、
allowAbsoluteUrls: false設定 - 適用 SLA: 72 時間
企業システム向けパッチ適用 SLA テンプレート
横にスクロールして確認できます
| カテゴリ | CVSS / 条件 | パッチ適用 SLA | 検証スコープ | 通知先 |
|---|---|---|---|---|
| Critical-A | CVSS ≥ 9.0 + KEV 登録 | 24 時間以内 | 本番疎通＋スモーク | CISO・経営層 |
| Critical-B | CVSS ≥ 9.0 | 72 時間以内 | 本番疎通＋スモーク＋単体 | CISO |
| High | CVSS 7.0-8.9 | 7 日以内 | 単体＋結合＋スモーク | セキュリティ責任者 |
| Medium | CVSS 4.0-6.9 | 30 日以内 | 通常リリース | プロジェクト責任者 |
| Low | CVSS < 4.0 | 90 日以内（次回定期） | 通常リリース | 開発担当 |
優先度判定フロー
1. NVD で CVSS 取得
2. CISA KEV カタログ登録の有無確認 → 登録なら Critical-A
3. 暴露面評価
- 公開エンドポイントから到達可能 → 1 段階上げる
- 認証後のみ到達 → 据え置き
- 内部・閉域のみ → 1 段階下げる
4. 業務影響評価
- 決済／個人情報／契約 → 1 段階上げる
- 社内のみ → 据え置き
5. 確定 SLA で着手
npm audit / Snyk / Dependabot の運用設計
横にスクロールして確認できます
| ツール | 強み | 弱み | 推奨用途 |
|---|---|---|---|
| npm audit | 標準・無料 | 誤検知多い・ノイズ高い | CI 早期検知 |
| Snyk | 補完情報豊富・修正提案 | 有料・量に応じた課金 | セキュリティ運用主軸 |
| Dependabot | GitHub 統合・PR 自動 | バージョン上げ過ぎ問題 | 軽い更新の自動化 |
中堅企業では「Dependabot を主軸に Snyk を有料併用、npm audit は CI ゲートのみ」の組合せがコストパフォーマンスで最適化される。
中堅企業の運用例
前提: 従業員 200 名、情シス 2 名、Node.js プロジェクト 12 本、axios 全プロジェクトで利用
体制
- 検知: Dependabot（無料）+ Snyk Pro（年 60 万円）
- 判定: 情シス担当 1 名が SLA テーブル参照で 30 分以内に判定
- 適用: SRE 兼任 1 名が修正 PR レビュー＋本番反映
2026 年実績（年初〜4 月）
- Critical-A 対応: 1 件（CVE-2026-40175、24 時間以内に全 12 本更新完了）
- Critical-B 対応: 1 件（CVE-2026-34621、48 時間以内）
- 月平均 High 適用件数: 3.2 件
- 月平均運用工数: 12 時間
GXOの見解
セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。
GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。
GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。
実務判断のポイント
この記事は、経営者、CIO、情シス、セキュリティ担当、開発責任者向けです。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。axios 脆弱性 年表 2024-2026｜CVE 一覧・CVSS スコア・影響バージョン・パッチ適用 SLA テンプレートに関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。
GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。
GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、診断、監査、保守契約、月次レポート、緊急対応支援へ接続。さらに、チェックリスト型診断を入口に、継続監視・改善支援へ展開。
実行までの進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
90日で進める実装ロードマップ
横にスクロールして確認できます
| 期間 | やること | 成果物 | 判断ポイント |
|---|---|---|---|
| 1〜2週目 | 現状業務、利用ツール、データ、担当者、外部委託先を棚卸しする | 業務一覧、システム一覧、課題一覧 | 本当に解くべき課題が、流行テーマではなく業務上の損失にひも付いているか |
| 3〜4週目 | 優先度、リスク、費用対効果、社内体制を整理する | 優先順位表、概算費用、リスク表 | すぐ着手する範囲と、後回しにする範囲を分けられているか |
| 5〜8週目 | 小さな検証、要件定義、ベンダー比較、社内説明資料を作る | PoC計画、RFP、稟議資料 | 検証結果を本番投資の判断に使える形で記録しているか |
| 9〜12週目 | 本番化、運用ルール、教育、月次レビューを設計する | 運用手順、KPI、改善バックログ | 導入後の責任者と改善サイクルが決まっているか |
部門別に確認すべき論点
経営層は、axios 脆弱性 年表 2024-2026｜CVE 一覧・CVSS スコア・影響バージョン・パッチ適用 SLA テンプレートが売上、粗利、採用、顧客維持、リスク低減のどれに効くのかを確認する必要があります。単なる効率化として扱うと、投資判断が後回しになり、現場任せの小さな改善で止まりやすくなります。
DX責任者や情シスは、既存システムとの接続、認証、権限、ログ、保守体制、外部ベンダーとの責任分界を確認します。ここを曖昧にすると、導入直後は動いても、問い合わせ増加、障害対応、改修費用で現場負荷が増えます。
業務部門は、例外処理、承認、差し戻し、手作業で補っている判断を洗い出します。表面上の手順だけを自動化しても、例外が多い業務では成果が出にくいため、現場の暗黙知を要件に変換することが重要です。
管理部門は、契約、個人情報、補助金、会計処理、監査証跡、社内規程との整合性を確認します。特に制度、法務、セキュリティ、価格が絡むテーマでは、公開情報と社内ルールの両方を確認してから進めるべきです。
KPIと効果測定の設計
効果測定では、導入有無だけでなく、問い合わせ、初回相談、対応時間、差し戻し率、問い合わせ削減、障害件数、監査指摘、顧客満足度などを分けて見ます。GXOでは、初回相談の段階で「何をもって成功とするか」を決め、検証後に継続投資できる形へ落とし込みます。
横にスクロールして確認できます
| KPI | 見る理由 | 測定例 |
|---|---|---|
| 対応時間 | 現場負荷と原価に直結するため | 1件あたり処理時間、月間削減時間 |
| 差し戻し率 | 要件やデータ品質の問題が見えるため | 申請、見積、問い合わせの再作業率 |
| 初回相談 | 問い合わせや初回相談の状況を確認するため | CTAクリック、問い合わせ数、初回相談数 |
| 運用定着率 | 導入後に使われ続けているかを見るため | 月次利用、更新頻度、レビュー実施率 |
| リスク低減 | 障害、漏えい、監査指摘を減らすため | 未対応脆弱性、権限不備、復旧時間 |
相談前に用意すると判断が早くなる資料
- 現在の業務フロー、担当者、月間件数、処理時間
- 利用中のSaaS、基幹システム、Excel、外部委託先の一覧
- 直近のトラブル、問い合わせ、手戻り、障害、監査指摘の記録
- 投資できる予算感、希望時期、社内の承認者
- 個人情報、機密情報、外部送信、契約条件に関する制約
- 既に検討したツール、ベンダー、見積、PoC結果
- 成功時に増やしたい売上、減らしたい工数、避けたい損失
GXOが支援する場合の進め方
GXOが支援する場合は、最初に記事テーマをそのまま提案にせず、現場の制約と経営上の目的に分解します。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応の相談を入口に、要件定義、RFP、ベンダー比較、実装、運用改善まで接続できるかを確認します。
短期的には、課題整理、現状棚卸し、優先順位付け、概算費用、実行計画をまとめます。中期的には、PoCや小規模実装を通じて、データ品質、権限、運用負荷、費用対効果を検証します。長期的には、月次レビュー、改善バックログ、追加開発、セキュリティ確認を継続し、投資を一度きりで終わらせない状態を作ります。
重要なのは、記事を読んだ直後に「問い合わせるかどうか」ではなく、「自社では何を確認すべきか」「どの段階から外部支援を入れるべきか」が明確になることです。そのため、GXOでは相談前の論点整理から支援し、必要に応じて診断、要件定義、実装、保守まで段階的に進めます。
よくある質問（FAQ）
Q. axios を使い続けるのと fetch に置換するのと、どちらが安全？ A. 短期は axios の最新版維持が低コスト。長期で大規模リファクタの計画があるなら fetch / ky への移行も選択肢。詳細は別記事「axios 代替ライブラリ比較」参照。
Q. SBOM（ソフトウェア部品表）作成は必要？ A. 経済産業省「ソフトウェア管理に向けた SBOM の導入に関する手引」（2024 年改訂）に準拠する場合は必須。axios のような OSS は SBOM 上で逐次更新管理する想定。
Q. CVSS 10.0 の CVE で 24 時間以内に全プロジェクト更新は現実的？ A. 12 本程度までは 2 名体制で可能。30 本超なら CI/CD 自動化と canary release の整備が前提条件。
参考資料
- NVD（National Vulnerability Database）axios 検索結果
- CISA KEV（Known Exploited Vulnerabilities）カタログ
- 経済産業省「ソフトウェア管理に向けた SBOM の導入に関する手引」2024 年改訂版
- IPA「情報セキュリティ 10 大脅威 2026（組織編）」
axios 脆弱性管理の体制構築や SBOM 整備の支援が必要な場合は、GXO のセキュリティ運用支援サービスまでお問い合わせください。中堅企業向けに Dependabot+Snyk の組合せ導入と SLA テンプレート整備をワンストップで支援しています。
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
