CVE-2026-54763（Traefik）— 剥がしたはずのヘッダが後段に届く理由

リバースプロキシが「認証済みのIDを詐称するヘッダを剥がした」あとで、剥がしたはずのヘッダが後段のアプリケーションに届く。CVE-2026-54763 はそういう脆弱性です。原因はハイフンとアンダースコアの扱いという、知らなければ絶対に気づけない正規化の非対称性でした。一次情報で確認した事実と、自分の環境を確認する手順を整理します。

要点

何が起きるのか — ハイフンとアンダースコアの非対称性

公式の説明は次のとおりです（原文）。

整理すると、次の3つの事実が重なったところに問題が生まれています。

1. プロキシは「正規形」でヘッダを剥がしていた。 Traefik は認証済みのIDを自前のヘッダに書き込む前に、クライアントが送りつけてきた同名ヘッダを削除します。ところが Go のヘッダ削除が正規化するのは大文字小文字とハイフンだけで、アンダースコアは区切り文字として扱われません。結果として、ハイフン表記の綴りは消えても、アンダースコア表記の兄弟はそのまま残ります。
2. 後段はハイフンとアンダースコアを区別しない。 CGI 系のインタフェースでは、ヘッダ名を大文字化し、ハイフンをアンダースコアに置換し、HTTP_ を前置してメタ変数名を作ります。したがって、ハイフン版とアンダースコア版は後段から見ると同じ名前になります。
3. プロキシが「消したつもり」のものが後段に届く。 残ったアンダースコア版が、Traefik が意図して設定した値と並んで（ForwardAuth の authResponseHeaders の経路では、意図した値の代わりに）後段に到達します。後段のアプリケーションは、それを信頼できるヘッダとして読み取ってしまいます。

後段の正規化ルール（一次情報）

ハイフンとアンダースコアが同一視されるのは実装依存の癖ではなく、規格に書かれた変換です。RFC 3875（CGI 1.1）の 4.1.18 節にはこうあります（原文）。

PHP のマニュアルの $_SERVER の項にも、同じ趣旨の記述があります（原文）。

つまり、ハイフン版のヘッダ名とアンダースコア版のヘッダ名は、この変換を経ると完全に同じキーになります。プロキシ側が片方しか消していなければ、後段は残ったほうを読みます。

なぜ nginx には underscores_in_headers があるのか

この問題は今回初めて見つかったものではなく、リバースプロキシの世界では以前から知られた地雷です。nginx には、まさにこのための設定があります。公式ドキュメント（ngx_http_core_module）の記述は次のとおりです（原文）。

• 構文： underscores_in_headers on | off;
• 既定値： underscores_in_headers off;
• コンテキスト： http, server

既定が off であること自体が、この危険性への設計上の回答になっています。ただし、細かいところを正確に読んでください。off のとき nginx が行うのは「単純に削除する」ことではなく「無効なヘッダとして印を付ける」ことで、その後どうなるかは ignore_invalid_headers ディレクティブに委ねられます。「nginx はアンダースコア付きヘッダを既定で捨てる」という説明は、結果としては近いものの、因果の記述としては不正確です。

Traefik 側の修正と、注意が必要な点

修正版は v2.11.51 / v3.6.22 / v3.7.6 です。v3.6.22 のリリースノートには、この CVE が修正対象として明記されています。

スコアが2つあることについて

この CVE には性格の異なるスコアが2つ付いています。どちらか一方だけを引用すると印象が大きく変わるため、出典とともに扱うのが正確です。

10.0 になっているのは、CVSS 3.1 のベクタで Scope が Changed（S:C）と評価されているためです。プロキシという境界を越えて後段の判断を狂わせる、という性質がそのまま反映されています。

また、CISA Coordinator による SSVC の判定（2026年7月8日）は exploitation: none／automatable: yes／technicalImpact: partial でした。2026年8月3日版の CISA KEV カタログを検索した限り、この CVE は収載されていません。

自分の環境を確認する手順

いずれも自分が管理する環境に対して行う確認です。

1. Traefik の版を確認する。 実行中のバイナリまたはコンテナイメージのタグを見ます。

   # バイナリ
   traefik version
   
   # コンテナ（イメージのタグと、コンテナ内での版の両方を見る）
   docker ps --format '{{.Image}}'
   docker exec <container> traefik version

   イメージタグと実際の版が食い違うことがあるので、タグではなく実行中の版で判断してください。
2. 該当ミドルウェアを使っているかを確認する。 動的設定の中に basicAuth / digestAuth / forwardAuth があるか、そしてそれらが認証済みのIDを後段へ渡す設定（ヘッダ名を指定するオプションや、ForwardAuth の authResponseHeaders）になっているかを見ます。IDを後段へ渡していなければ、この経路の露出はありません。
3. 後段がハイフンとアンダースコアを同一視するかを確認する。 PHP・CGI・FastCGI を経由する構成は、上の RFC 3875 の変換規則により該当します。アプリケーションフレームワークによっては独自の正規化を行うため、実際にどうなるかは後段の実装で確認してください。
4. エントリポイントの設定を確認する。 修正版へ上げたあと、該当するエントリポイントに underscoreHeadersStrategy を明示的に設定したかを確認します。設定していなければ keep（従来どおり）のままです。
5. 前段に nginx がある場合は既定値を確認する。 underscores_in_headers を明示的に on にしていないか。過去に「アンダースコア付きの独自ヘッダが後段に届かない」という理由で on にした設定が残っていることがあります。

設計上の一般化 — 「正規化のずれ」を疑う場所

今回の欠陥は Traefik 固有の実装ミスというより、境界をまたぐたびに正規化の定義が変わるという構造的な問題です。同じ形の落とし穴は、次のような場所に潜みます。

• 大文字小文字。 HTTPヘッダ名は本来大文字小文字を区別しませんが、それを自前で扱うコードでは区別してしまいがちです（今回の CWE-178 がまさにこれです）。
• 区切り文字の等価性。 ハイフンとアンダースコア、スペースとプラス、スラッシュの重複など。
• Unicode 正規化。 見た目が同じで符号位置が異なる文字。比較の前に正規化しているか。
• パーセントエンコーディングの復号回数。 どの層で何回デコードするか。
• 末尾のスラッシュ・大文字小文字を含むパス比較。 アクセス制御をパス文字列で行っている場合。

共通する対策の型はひとつです。剥がす側は「拒否リスト」ではなく「許可リスト」で考える。「危ないヘッダを消す」ではなく「後段へ渡してよいヘッダだけを通す」設計にすれば、綴りのバリエーションを数え漏らしても破綻しません。今回 Traefik に追加された reject という選択肢は、その発想に近い挙動です。