axiosに認証情報が盗まれる脆弱性、最新版へ今すぐ更新を CVE-2026-44494

世界中のアプリが通信に使っているaxios（アクシオス）に、認証情報が盗まれかねない2件の脆弱性が見つかり、修正版が公開されました。axiosは、ブラウザやサーバー上のプログラムが外部のサーバーとデータをやり取りするための「HTTP通信ライブラリ」で、npm（ネットの部品置き場）から週1億回以上ダウンロードされる定番部品です。自分で使った覚えがなくても、社内のアプリや外部サービスが内部で取り込んでいる可能性が高いのが特徴です。

問題は2つあります。1つは、社内サーバーやクラウドの管理情報への通信を遮断する設定（NO_PROXY）をすり抜けて、外部からアクセスを誘導できるCVE-2026-44492。もう1つは、アプリが送るすべての通信を攻撃者のサーバー経由に切り替えてしまうCVE-2026-44494です。いずれも修正版のaxios 1.16.0（および旧系列の0.32.0）で塞がれ、現在の最新は1.17.0です。

脆弱性そのものの開示は2026年5月29日でしたが、危険度を示す国際スコアが各データベースに登録されて広く知られるようになったのは6月に入ってからです。今のところ実際の攻撃に使われたという報告はありませんが、axiosを取り込んでいるアプリの数が膨大なため、自社の依存関係を確認して更新を済ませておくのが安全です。

axiosとは何で、なぜほぼ全員に関係するのか

axiosは、JavaScript（ウェブやサーバーで動く言語）のプログラムから他のサーバーへデータを取りに行ったり送ったりするための部品です。「APIを呼ぶ」「外部サービスと連携する」といった処理の大半が、こうした通信ライブラリの上で動いています。axiosはその分野で最も広く使われている定番で、週1億回以上のダウンロードがあります。

やっかいなのは、自分のアプリが直接axiosを使っていなくても、取り込んでいる別の部品（ライブラリ）が内部でaxiosを呼んでいるケースが非常に多いことです。これを「間接依存」と呼びます。そのため「うちはaxiosなんて使っていない」と思っていても、依存関係をたどると奥のほうで使われていることが珍しくありません。下の表のように、まずは自分の立場でどう関係するかを確認するのが出発点になります。

2件のうち、より直接的に危ないのはサーバー側（Node.js）で動かしている場合です。とりわけ、AWSやGoogle Cloudといったクラウド上でaxiosを使っているサービスは、後述するクラウドの認証情報の流出につながるため、優先して対応すべきです。

2つの脆弱性の概要

どちらも、axiosが「プロキシ」（通信を中継するサーバー）をどう扱うかに関わる穴です。性質と、攻撃が成立するための前提が異なるため、まず一覧で違いを押さえます。危険度の数字は、深刻さを0〜10で表す国際的な共通スコア「CVSS」です。

違いを一言でいえば、CVE-2026-44492は「守りの壁に空いた抜け道」、CVE-2026-44494は「成立すれば最悪だが、別の穴とセットで初めて効く」タイプです。後者の「前提」については、数字の見え方とあわせて後の節で詳しく触れます。

狙われると何が起きるのか

axiosは最も使われる通信部品で、アプリが扱う情報のほぼすべてがここを通ります。狙うのは、クラウドへの侵入口を探すランサムウェア集団、内部APIを物色する産業スパイ、盗んだ認証情報を闇市場で売るアクセスブローカーです。持ち去られるのは、AWSやGoogle Cloudの一時認証キー、社内APIのアクセストークン、ログインのID・パスワード、リクエスト内の個人情報です。NO_PROXYという遮断設定がすり抜けられた瞬間、本来は外に出るはずのない経路で、クラウドの管理サーバーに置かれた認証キーが相手の手元へ届いてしまいます。

鍵を一本抜かれれば、その権限でストレージを読まれ、データベースを覗かれ、隣のサーバーへ横移動されます。盗んだ認証情報を闇市場で転売し、買った集団がランサムウェアを仕込む二段構えも常態です。プロトタイプ汚染を突かれた場合はさらに直接的で、アプリが送る全通信が攻撃者のサーバーを経由し、ログインのたびにID・パスワードが記録され、受け取る応答も気づかぬうちにすり替えられます。利用者には何も変わって見えません。

そして被害の責任は、axiosの作者ではなく、それを組み込んだサービスの運営会社に返ってきます。顧客の個人情報が漏れれば個人情報保護委員会への報告と本人通知が義務づけられ、規模次第で損害賠償と信用失墜がのしかかります。CVSSの8点台という数字に、事後対応のコストは含まれていません。修正版が出ている今、依存関係を一行確認して更新できるかが、その分かれ目です。

それぞれの穴をくわしく見る

CVE-2026-44492: 遮断設定をすり抜けてクラウドの鍵に届くSSRF

サーバー上のプログラムは、社内サーバーやクラウドの管理情報といった「外に出してはいけない宛先」への通信を、NO_PROXYという設定で遮断します。axiosはこの判定を行うshouldBypassProxyという処理を持っていますが、アドレスの特殊な書き方を正しく見分けられない不備がありました。これがCVE-2026-44492です。

具体的には、IPアドレスには「IPv4」と「IPv6」という2つの表記があり、127.0.0.1のようなIPv4アドレスは、IPv6では::ffff:7f00:1という別の書き方でも同じ宛先を指せます。NO_PROXYに127.0.0.1と書いて遮断していても、攻撃者が::ffff:7f00:1の形でアクセス先を指定すると、axiosは「これは遮断対象ではない」と誤判定し、通信が通ってしまいます。とりわけ危ないのが、クラウドの管理情報を返すメタデータサーバー（169.254.169.254）で、ここには一時的な認証キーが置かれています。これを書き換え表記（::ffff:a9fe:a9fe）で突かれると、クラウドの認証情報が抜き取られる恐れがあります。これは「SSRF（サーバー側リクエスト強要）」と呼ばれる、サーバーをだまして内部の宛先へ通信させる典型的な攻撃です。

この穴は、実は以前の脆弱性CVE-2025-62718を直した修正（1.15.0で導入）が不完全だったために残ったものです。前回はIPv4の書き方しか想定しておらず、IPv6の書き換え表記が抜け道として残っていました。アドレスの「正規化」（表記をそろえて比べること）の難しさが、同じ穴を二度開けてしまった形です。

CVE-2026-44494: 通信を丸ごと乗っ取るプロトタイプ汚染

もう1件は、成立すれば影響が極めて大きい中間者攻撃（MITM）につながる穴です。中間者攻撃とは、通信の途中に攻撃者が割り込み、やり取りを盗み見たり書き換えたりする手口を指します。鍵になるのが「プロトタイプ汚染」という、JavaScript特有の弱点です。

JavaScriptには、すべての設定オブジェクトが共有する「ひな型（プロトタイプ）」があります。ここに攻撃者がproxyという項目を勝手に書き込めると、axiosは自分の設定にプロキシ指定が無いと判断したとき、このひな型に書かれた値を拾ってしまいます。axiosの通信処理がプロキシ設定を読む際にこのひな型までたどってしまうため、攻撃者のサーバーがプロキシとして差し込まれ、以降の通信がすべてそこを経由します。開発者のコードは見た目には完全に正常で、axios.get(...)と普通に書いているだけなのに、通信が乗っ取られるのが恐ろしい点です。報告者の実証では、Basic認証のIDとパスワードが攻撃者のサーバーにそのまま記録される様子が確認されています。

ただし、この穴を突くには重要な前提があります。axios単体ではプロトタイプ汚染を起こせません。同じアプリが使っている別のライブラリにプロトタイプ汚染の穴があり、そこを起点にひな型を書き換えられることが条件です。逆に言えば、その下地さえあれば、開発者が一切ミスをしていなくてもaxios側が自動的に汚染された値を使ってしまう、という連鎖（これを「ガジェット」と呼びます）になっています。この「前提つきの最悪」という性質が、数字の受け取り方を難しくしています。

CVSSの数字だけで慌てないために

報告者はCVE-2026-44494を自己評価で「9.4（緊急）」とし、一部のデータベースも高いスコアを付けています。ただ、ここは冷静に見る必要があります。前述のとおりこの穴は単体では発動せず、別のライブラリにプロトタイプ汚染の穴が同居していて初めて効きます。つまり、スコアが示すのは「条件がすべて揃ったときの最悪値」であって、すべてのaxios利用環境がいま同じ危険度にある、という意味ではありません。

この「数字の独り歩き」は、axiosをめぐって以前にも議論になりました。ITmediaは別のプロトタイプ汚染系の脆弱性について、最高スコア10と評価されながら実際の悪用には厳しい条件が必要で、運用上のリスクとスコアに乖離があるとする専門家の指摘を伝えています。CVSSは「理論上の最悪」を測る物差しであり、自分の環境での現実的なリスクは、依存関係に汚染の起点となる穴がないか、通信先URLを外部から操作される作りになっていないか、を併せて見ないと判断できません。

一方で、もう1件のCVE-2026-44492は前提が軽く、より直接的です。攻撃者がアクセス先のURLを指定できる作り（外部から受け取った値で通信先を組み立てるような処理）であれば、それだけで遮断設定がすり抜けられます。クラウド上でaxiosを動かしているなら、こちらは「条件が揃えば」ではなく「今そこにある抜け道」として扱うべきです。数字の大小よりも、自分の作りと前提条件に当てはめて優先順位を決めるのが、慌てず確実に直すコツです。

自分のaxiosは更新が必要か（バージョン早見表）

いま使っているバージョンは、プロジェクトのフォルダでnpm ls axiosと打つと確認できます。間接依存も含めて、どのバージョンが入っているかが一覧で出ます。下の表で自分の番号を照合してください。修正版は1.16.0以上（最新は1.17.0）、旧0系列を使っている場合は0.32.0です。

なお、可能であれば旧0系列（0.x）ではなく、現行の1系列の最新版へ移行しておくのが安全です。0系列はメンテナンスが細り、過去にも複数の脆弱性が積み残されてきた経緯があります。間接依存で古いaxiosが入っている場合は、それを呼んでいる親の部品の更新が必要になることもあるため、npm ls axiosで「どの部品が古いaxiosを連れてきているのか」を先に把握しておくと段取りが楽になります。

いま取るべき対応

最も確実な対策は、axiosを1.16.0以上（できれば最新の1.17.0）、旧系列なら0.32.0へ更新することです。直接依存していればnpm install axios@latestで上げられます。間接依存の場合は、npm auditや脆弱性データベースで該当を確認し、親の部品の更新か、npmの上書き機能（overrides）で安全なバージョンを強制します。

すぐに更新できない事情がある場合の当座の手当てとしては、外部から受け取った値をそのまま通信先のURLに使わない、クラウドのメタデータサーバーへのアクセスを別の仕組み（IMDSv2やネットワーク側の制限）でも止めておく、依存関係にプロトタイプ汚染の既知の穴が無いかを点検する、といった併用が現実的です。ただしこれらは時間稼ぎであり、根本対策はあくまで本体の更新です。今のところ実際の攻撃は確認されていませんが、修正の公開後は穴の場所が把握されやすくなるため、先送りはそのまま危険の蓄積になります。

なぜaxiosは脆弱性が続くのか

axiosは2026年に入ってから、プロキシやプロトタイプ汚染にまつわる脆弱性が立て続けに見つかっています。今回の2件も、研究者がソースコードを丹念に監査する中で見つけた一連の「ガジェット型」の穴の一部です。背景には、JavaScriptのプロトタイプという仕組みが、便利さと引き換えに「想定外の値が紛れ込む」経路を作りやすいという構造的な事情があります。プロキシ周りの判定も、IPアドレスの表記ゆれという細かな差を完全にそろえるのが難しく、一度直しても抜け道が残りがちです。

さらにaxiosは、2026年3月にメンテナーのアカウントが乗っ取られ、悪意あるバージョンが一時的に公開されるサプライチェーン攻撃の標的にもなりました。利用者が桁違いに多い定番部品は、それだけ攻撃者にとっても旨味が大きく、コード自体の穴と、配布経路への攻撃の両面から狙われ続けます。npmが依存パッケージの自動実行を止める方向へ動いたのも、こうした流れと地続きです。

だからこそ、外から取り込む部品がどのバージョンで、既知の穴を抱えていないかを継続的に点検する発想が要ります。自分の依存関係を貼り付けるだけで危険なバージョンを洗い出せるOSSの脆弱性チェックの仕組みを一度通しておくと、今回のような「気づけば古いaxiosが奥に潜んでいた」を早めに拾えます。定番ほど更新を後回しにしがちですが、使われている数の多さがそのまま被害の広さに直結する点を忘れないことが大切です。

参照元

• ▸ axios公式アドバイザリ - GHSA-pjwm-pj3p-43mv（CVE-2026-44492 / NO_PROXYバイパス）
• ▸ axios公式アドバイザリ - GHSA-35jp-ww65-95wh（CVE-2026-44494 / プロトタイプ汚染MITM）
• ▸ NVD - CVE-2026-44492
• ▸ NVD - CVE-2026-44494
• ▸ axios - リリースノート（v1.16.0）
• ▸ ITmedia - 脆弱性スコア10/10の“独り歩き”に警鐘（Axiosの過去事例）
• ▸ npm - axios パッケージページ