Traefik の認証ミドルウェアがアンダースコア版ヘッダを消し残す（CVSS 10.0）

Critical（CVSS 10.0）に分類されるTraefik Labs Traefik v2.11.51 未満 / v3.0.0 以上 v3.6.22 未満 / v3.7.0 以上 v3.7.6 未満の脆弱性です。Traefik は HTTP のリバースプロキシ兼ロードバランサで、Kubernetes の Ingress Controller や Docker 環境の入口として広く使われている。その BasicAuth / DigestAuth / ForwardAuth ミドルウェアは、認証結果を後段のアプリへ伝えるために `X-Forwarded-User` のような ID ヘッダを自分で書き込む。このとき、クライアントが同じ名前のヘッダを送りつけて成りすますのを防ぐため、**書き込む前に同名ヘッダを剥がす**処理が入っている。 欠陥はこの剥がし方にある。Traefik はハイフン区切りの正規形（`X-Forwarded-User` など）だけを剥がしており、**アンダースコア版（`X_Forwarded_User`）を見ていなかった**。ところが後段の多くの実装は、ヘッダ名を環境変数などへ写すときにハイフンとアンダースコアを同じに正規化する（PHP の `$_SERVER['HTTP_X_FORWARDED_USER']`、Nginx の `$http_` 変数、CGI 系のフレームワークが典型である）。つまり Traefik から見れば別名の無害なヘッダが、後段のアプリから見ると認証済みの ID ヘッダそのものとして読める。 結果として、保護されたルートに到達できる攻撃者はアンダースコア版のヘッダを注入するだけで、Traefik が設定したはずの値と並んで（ForwardAuth の `authResponseHeaders` 経路では、値の代わりに）自分の指定した ID を後段へ届けられる。認証そのものは通っているのに、**誰として通ったか**が攻撃者の指定に置き換わる。管理者ユーザー名を名乗る、別テナントの ID を名乗る、といった形になる。 NVD の CVSS 3.1 基本値は 10.0（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N）で Critical。未認証・低難度・利用者操作不要で、**スコープ変更（S:C）**が付いている。影響が Traefik の外（後段のアプリの認可判断）へ出るためである。一方、GitHub Security Advisory（GHSA-x677-9fxg-v5c5）側は CVSS 4.0 で 7.8 HIGH としており、評価に差がある。この差は 4.0 が「Traefik 自身の機密性・完全性は損なわれない（VC:N/VI:N）が、後段システムの機密性・完全性が損なわれる（SC:H/SI:H）」と分けて表現しているためで、危険度の見立てが割れているというより、どこを評価対象に置いたかの違いである。**後段のアプリを含めて見れば深刻である**という点は両者で一致している。 対応版は v2.11.51 / v3.6.22 / v3.7.6 だが、**更新しただけでは挙動は変わらない**。入ったのは認証ミドルウェアの修正ではなく、エントリポイントの新設定 `underscoreHeadersStrategy` で、既定値は `keep`（素通し）である（2026-08-04 に修正コミット 108a5264 の差分で確認）。NVD の版レンジは 2.11.51 未満、3.0.0 以上 3.6.22 未満、3.7.0 以上 3.7.6 未満。NVD 公開日は2026年7月6日、最終更新は7月8日、vulnStatus は Analyzed。2026年8月3日時点で CISA KEV カタログには収載されていない。

まず版を確認する。`traefik version` で出る。Kubernetes なら `kubectl get deploy -A -o jsonpath='{range .items[*]}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i traefik` で実際に動いているイメージタグを見る。Helm の `values.yaml` に書いた版ではなく、**動いているイメージの版**を見ること。 次に、自分が影響を受ける構成かを見る。条件は2つで、(1) BasicAuth / DigestAuth / ForwardAuth のいずれかを使っている、(2) それらが後段へ渡す ID ヘッダを、後段のアプリが認可判断に使っている。後段が PHP・CGI・WSGI・Nginx のようにハイフンとアンダースコアを同じ変数へ写す実装なら該当する。ForwardAuth の `authResponseHeaders` にユーザー名やロールを載せている構成が最も危ない。 **ここが本件の要点である。更新しただけでは防御されない。** 修正コミット（108a5264）が入れたのは認証ミドルウェア側の修正ではなく、エントリポイントの新しい設定 **`underscoreHeadersStrategy`** である。変更されたのは `pkg/config/static/entrypoints.go` と `pkg/server/server_entrypoint_tcp.go`、および `docs/content/security/header-underscores.md`（新規）で、**既定値は `keep`＝これまでどおり素通し**である。したがって v2.11.51 / v3.6.22 / v3.7.6 へ上げても、設定を書かなければ挙動は変わらない。 恒久対応は **更新 ＋ エントリポイントに `underscoreHeadersStrategy` を明示する**ことである。値は3つ。 - `keep`（既定）… アンダースコア付きヘッダをそのまま転送する。**該当構成ではこのままにしない** - `delete` … 名前にアンダースコアを含むリクエストヘッダを黙って削除する - `reject` … そのヘッダを持つリクエストを 400 Bad Request で拒否する 後段がハイフン/アンダースコアを同一視する実装なら `delete` か `reject` を選ぶ。正規の用途でアンダースコア付きヘッダを使っているアプリが同居していないかだけ先に確認すること（`delete` は黙って消すので、消えたことに気づきにくい）。 **注意: アドバイザリ本文が案内している `allowHeadersWithUnderscores` というオプションは、実際に出荷されたコードには存在しない。** 実装された名前は `underscoreHeadersStrategy` である（2026-08-04 に修正コミットの差分で確認）。アドバイザリの文面どおりに設定を書くと、**設定したつもりで何も効いていない**状態になる。 オプションが無い版（v3.6.20 未満 / v3.7.6 未満の 3.7 系 / v2 系）を使い続ける場合の緩和策は、Traefik の手前か後段でアンダースコア付き ID ヘッダを落とすことである。後段が Nginx なら `underscores_in_headers` は既定 off なので、**既定のままにしておく**。 検知は、アクセスログにアンダースコア入りのヘッダ名が現れていないかを見る。Traefik のアクセスログでヘッダを記録していない構成が多いので、その場合は後段のアプリ側で「認証したユーザーと、アプリが認識したユーザーが食い違っている」記録を探すほうが早い。 優先順は、**インターネットに面していて ForwardAuth で SSO を組んでいる構成**が最も高い。

Traefik Labs Traefik v2.11.51 未満 / v3.0.0 以上 v3.6.22 未満 / v3.7.0 以上 v3.7.6 未満 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-54763）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。