ここ数週間、Axiosにとっては混乱の連続だった。
まず、大規模なサプライチェーン攻撃により、このパッケージが注目を集めることになった。そして、そのわずか数日後、クラウド環境全体が乗っ取られる恐れのある「深刻度10/10の脆弱性 脆弱性に関するニュースが報じられ始めた。
関連報道を読んだ方なら、次のような主張を目にしたことがあるでしょう：
- 「攻撃者はAWSの認証情報を盗み出すことができる」
- 「IMDSv2バイパス」
- 「リモートコード実行の連鎖」
それは大変ですね。
しかし、脆弱性 実際の環境でどのように振る舞うかを詳しく見てみると、話は変わってくる。
エクスプロイト 分析し、この問題を報告した研究者であるラウル・ベガ・デル・ヴァッレ氏と動作を確認した結果、あることが明らかになった：
標準的なNode.js環境では、脆弱性 現実的に悪用される脆弱性 。
その理由は単純です。この攻撃は不正なヘッダーの挿入に依存していますが、Node.jsではすでに何年も前から実行時レベルでこれをブロックしているからです。
だからといって、CVEが誤っているわけではありません。Axiosに潜む根本的な問題は実在し、その修正は正しい判断でした。しかし、これが本番環境におけるクラウドの容易な侵害につながるという主張は、厳密に検証すれば成り立ちません。実際には、この脆弱性を悪用するには、Node.jsのヘッダー検証をバイパスするカスタムアダプターなど、極めて特殊な条件が必要となるからです。
CVEの主張
CVE-2026-40175 は「ガジェットチェーン」脆弱性として説明されています：
- 依存関係におけるプロトタイプによる汚染
- Axiosが汚染された値を取得する
- CRLFヘッダーの挿入
- リクエストの不正送信 / SSRF
- AWS IMDSv2のバイパス
- 認証情報の盗難 → クラウド環境の侵害
理論上は、次のような形になります：
// 別の場所でのプロトタイプ汚染
オブジェクト.prototype['x-amz-target'] =
"dummy\r\n\r\nPUTapi HTTP/1.1\r\n" +
"Host: 169.254.169.254\r\n" +
"X-aws-ec2-metadata-token-ttl-seconds: 21600\r\n\r\nGET /ignore";
// 通常のアプリケーションコード
axios.get("https://internal.service");Axiosが設定をマージ → 汚染されたヘッダーを取得 → 悪意のあるリクエストを送信する。
理論上はそうなる。
Node.jsでは実際には何が起きているのか
問題は、この連鎖が実環境では途切れてしまうことです。
Axiosは内部でNode.jsの組み込みHTTPクライアントを使用しています：
http.request(...)
また、Node.jsは長年にわたり、ヘッダー内のCRLF文字を拒否してきました。
もし次のように試してみると：
http.request({
headers: {
"x-test": "hello\r\nInjected: yes"
}
});以下のものが含まれます：
TypeError [ERR_INVALID_CHAR]: ヘッダーの内容に無効な文字が含まれています
それは、リクエストが送信される前に発生します。
つまり、エクスプロイト 中核となる手法――CRLFヘッダーの挿入――は、すでに実行時レベルでブロックされている。
この件について、研究者に確認しました
これを確認するため、脆弱性報告した研究者であるラウル・ベガ・デル・ヴァッレ氏に直接話を聞いた。
彼の結論は、私たちが観察した内容と一致している：
- Node.jsはCRLFヘッダーのインジェクションをブロックします
- BunとDenoでも同様の現象が見られる
- その結果、標準的な環境では、この攻撃チェーンを現実的に実行することはできない
ラウルの言葉を借りれば：
「実際のアプリケーションでは……そんなことは起こらないはずだ……Node、Bun、Denoは単にCRLFをブロックするだけだ。」
彼はまた、次のように確認した：
「実際の運用環境では、そのようなことはあってはならない。」
こうした重要なニュアンスは、多くの報道では見落とされている。
なぜCVEは今も存在しているのか
では、実際に悪用できないのなら、なぜこれがCVEとして登録されているのでしょうか？
この問題は図書館レベルで実際に生じているからです。
Axiosは以前、安全でないヘッダー値を許可していました。ランタイムがそれらをブロックしたとしても、ライブラリ自体はそうした制約を強制していませんでした。
研究者は次のように説明した：
「インタプリタレベルではそうではないが、ライブラリレベルでは現実のものだ」とラウル・ベガ・デル・ヴァッレは語る
完全を期すために、もう1つ言及すべき例外的なケースがあります。Axiosでは、開発者がカスタムアダプターを使用してリクエストの送信方法を上書きすることができます。Node.jsに組み込まれている`http.request`に依存する代わりに、カスタムアダプターを使用すれば、HTTPリクエストを手動で構築して送信することが可能です。
理論上、あるアプリケーションが：
- カスタムAxiosアダプターを使用しています
- Node.jsのHTTPクライアントを完全にバイパスする
- そして、生のリクエストをソケットに直接書き込みます
そうなると、ヘッダーの検証も回避されてしまう可能性があります。その場合、CRLFインジェクションが再び可能になる恐れがあります。
とはいえ、これには非標準的な使用法や、組み込みの保護機能の意図的な無効化が必要となります。Axiosをそのまま使用している一般的なNode.jsアプリケーションには当てはまりません。
IMDSv2のバイパスについてはどうでしょうか？
これは物語の中で最も話題になっている部分だが、現実味に最も欠けている。
はい、その通知には次のようなリクエストが表示されています：
PUTapi
ホスト: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600
しかし、そこに到達するためには、攻撃者は以下のものが必要となります：
- 試作による汚染
- CRLFの挿入
- リクエスト・スマグリング
- 実行時の検証なし
Node.js では、その連鎖は早い段階で途切れてしまいます。
その研究者でさえ、この環境下ではIMDSv2のバイパスは現実的に不可能であると指摘したが、IMDSv1についてはさらに調査する価値があるかもしれないとも述べた。
なぜこれが「重大」と評価されたのか
「10/10」という評価は、最悪のケースにおける連鎖攻撃の可能性に基づくものであり、一般的な悪用可能性に基づくものではありません。
もし次のように仮定すると：
- プロトタイプによる汚染の可能性がある
- ヘッダーを挿入できる
- 内部サービスにアクセス可能です
- メタデータのエンドポイントが公開されています
そうだとすれば、その影響は甚大なものになる可能性があります。
しかし、そこには多くの前提が重なり合っている。
開発者が実際にすべきこと
「今すぐ手を止めて」という状況ではありませんが、無視していいものでもありません。
次のことを行うべきです：
- Axios を 1.15.0 以上にアップグレードしてください
- プロトタイプ汚染のリスクがないか 依存関係 検証してください
- SSRFの脆弱性とネットワークアクセスについて確認する
- 実行時の保護機能だけに頼らないようにする
CVEの見出しだけでなく、実際の攻撃対象領域に注目すべきです。
