axiosにまた脆弱性 ── ヘッダインジェクションでクラウドのメタデータが抜かれる話(CVE-2026-40175)
配信ステータス:未配信 配信URL:(配信済みになったら記入)
台本
オープニング
【ジングル】 はい、どうもこんにちは。「雨宿りと WEB の小噺」、始まりました。Keeth こと桑原です。 今回もちょっとだけ、雨宿りしていきませんか。 今回のお題はですね、「axiosにまた脆弱性 ── ヘッダインジェクションでクラウドのメタデータが抜かれる話」。ちょっと面白い、いや怖い話なんで、まぁ聞いてってください。
本題
まず axios とは何か(知らない人向けのおさらい)
- JavaScriptで最もよく使われるHTTPクライアントライブラリの一つ
- ブラウザでもNode.jsでも動く、npmのダウンロード数は週に数億回レベル
- つまり「世界中の膨大な数のWebアプリで使われているライブラリ」に脆弱性が見つかった、という話
今回の脆弱性:CVE-2026-40175 のざっくり概要
- 「ヘッダインジェクションチェーン経由でクラウドのメタデータが抜かれる」という脆弱性
- 対象バージョンは axios 1.15.0 未満。使っていたらアップデート推奨
- 単体では成立しない「連鎖型攻撃(チェーン攻撃)」なのがポイント。後で詳しく話す
攻撃の第1段階:プロトタイプ汚染でヘッダを仕込む
- axios はリクエストヘッダを組み立てるとき、オブジェクトのプロパティをマージして使う
- ここで問題になるのが「プロトタイプ汚染(Prototype Pollution)」という別の攻撃手法
- プロトタイプ汚染とは、JavaScriptの
Object.prototypeを汚染することで、すべてのオブジェクトに意図しないプロパティを追加できてしまう脆弱性のこと - これを使うと
x-amz-targetのような AWS 向けの特殊ヘッダを、axios が使うオブジェクトに密かに注入できてしまっていた
攻撃の第2段階:CRLF インジェクションでヘッダを増殖させる
- HTTP のヘッダはテキストで構成されており、1行1ヘッダ。行の区切りは CRLF(
\r\n) - ヘッダの「値」の中に改行文字(CRLF)が含まれると、その後ろを「新しいヘッダ」として解釈させることができる
- 例えばヘッダ値に
hoge\r\nX-Injected: evilを仕込めば、実質2つのヘッダが送られる - axios は以前のバージョンではこのCRLFを含むヘッダ値を拒否していなかった
- HTTP のヘッダはテキストで構成されており、1行1ヘッダ。行の区切りは CRLF(
攻撃の第3段階:AWS IMDS(インスタンスメタデータサービス)を突く
- AWS の EC2 インスタンスには
http://169.254.169.254/というマジックIPがあり、ここにアクセスするとクラウドのメタデータが取れる - 具体的には IAM ロールの一時的なアクセスキーやシークレットキーまで取得できてしまう
- このメタデータサービス(IMDS)は「同じEC2の中からのリクエストなら認証なしで応答する」設計になっている
- 最近の IMDSv2 ではトークン方式の保護があるが、
x-amz-targetなどの特殊ヘッダを使ったリクエストを細工することで、これをすり抜けるルートが作れた
- AWS の EC2 インスタンスには
3段階がつながるとどうなるか
- 攻撃者がどこかのライブラリ(axiosとは別)のプロトタイプ汚染を悪用
- → axios のヘッダオブジェクトに
x-amz-targetなどのプロパティが混入 - → そのヘッダ値にCRLFが含まれていれば、任意のヘッダを追加注入
- → メタデータサービスへのリクエストを細工してクラウドの認証情報(IAMキーなど)を窃取
- この一連の流れが「ヘッダインジェクションチェーン」と呼ばれる所以
修正PRで何が変わったか(axios 1.15.0)
- 修正の核心は「不正なヘッダ値を持ち込んだ時点で拒否する」というシンプルな防御
- 具体的には、ヘッダの値にCRLF(
\r\n)や制御文字が含まれる場合はエラーを投げるよう変更 - プロトタイプ由来のプロパティを安易にヘッダとしてマージしないよう、ヘッダ組み立て処理の境界を厳格化
- おまけとして
lib/core/Axios.jsのエラースタック結合ロジックも見直し、スタック文字列の結合処理を安全側に修正
「チェーン攻撃のガジェット」という概念が重要
- axios 単体では攻撃は成立しない。プロトタイプ汚染ができる別の脆弱性が前提
- しかし axios が「その攻撃の最後のピース(ガジェット)」として機能してしまっていた
- セキュリティの世界では、単体では無害でも別の脆弱性と組み合わせると危険になるコードのことを「ガジェット」と呼ぶ
- 「うちのコードは直接攻撃されないから大丈夫」という発想が甘い理由がこれ
開発者として今すぐやるべきこと
- axios を使っているプロジェクトは
npm ls axiosで使用バージョンを確認 - 1.15.0 未満であれば即アップデート(
npm update axios) - AWS 環境に限らず、GCP や Azure にも類似のメタデータエンドポイントが存在するため、クラウド環境で動いているサービスは特に注意
- また、依存ライブラリのプロトタイプ汚染チェックも合わせて実施しておくと安心
- axios を使っているプロジェクトは
エンディング
【ジングル】 さて、そろそろ今回もお時間です。 面白かったよーという方は、ぜひチャンネル登録もお願いします。話してほしいトピックや感想は、概要欄のフォームか 𝕏 で「WEB 小噺」でつぶやいてください。web はアルファベット、「小噺」は漢字でもひらがなでも大丈夫です! それでは、また雨宿りしに来てください。お相手は Keeth でした。さようなら! 【ジングル】
📚 参考情報
- 脆弱性の概要
- CVE-2026-40175:axios のヘッダインジェクションチェーンによるクラウドメタデータ窃取
- 対象バージョン:axios 1.15.0 未満
- 修正版 1.15.0 で、ヘッダ値の CRLF・制御文字を拒否するよう変更
- 攻撃チェーンの3段階
- ① 別ライブラリのプロトタイプ汚染で axios のヘッダオブジェクトに
x-amz-target等を混入 - ② CRLF インジェクションで任意のヘッダを追加注入
- ③ AWS IMDS(
169.254.169.254)を突いて IAM の一時認証情報を窃取 - 単体では無害でも他の脆弱性と組み合わさると危険になる「ガジェット」という考え方がポイント
- ① 別ライブラリのプロトタイプ汚染で axios のヘッダオブジェクトに
- 開発者が今すぐやるべきこと
npm ls axiosで使用バージョンを確認し、1.15.0 未満ならnpm update axios- AWS に限らず GCP・Azure の類似メタデータエンドポイントにも注意
- 依存ライブラリのプロトタイプ汚染対策も合わせて確認
- 引用元
🎙️ 収録メモ
- トーン
- 冒頭:軽いつかみ、でもちょっと不穏
- 攻撃チェーンの解説:段階を追って丁寧に、緊張感を持たせる
- まとめ:実務的、行動喚起
- 強調ポイント
- 「ヘッダインジェクションチェーン」という一連の流れ
- 「ガジェット」という概念
- 「今すぐやるべきこと」(
npm update axios)
- 尺
- 合計:約8〜10分
- オープニング:30秒
- 本編:7〜9分
- クロージング:30秒
- タグ
axios #CVE202640175 #脆弱性 #セキュリティ #プロトタイプ汚染 #AWS #IMDS #npm