GHSA-3q9r-p662-5j8m Traefik: ForwardAuth middleware leaks X-Forwarded-Port spoofing via untrusted X-Forwarded-Proto when trustForwardHeader=false
SummaryThere is a medium severity vulnerability in Traefik's ForwardAuth middleware. Even when configured with `trustForwardHeader: false`, Traefik derives the `X-Forwarded-Port` header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an `X-Forwarded-Proto: https` header over a plain HTTP connection and cause Traefik to forward `X-Forwarded-Port: 443` to the auth service, bypassing port-based authorization checks. This is a regression of the incomplete fix for GHSA-6384-m2mw-rf54, which addressed the `X-Forwarded-Proto` and `X-Forwarded-Prefix` spoofing vectors but missed the `X-Forwarded-Port` vector.Patcheshttps://github.com/traefik/traefik/releases/tag/v2.11.51https://github.com/traefik/traefik/releases/tag/v3.6.22https://github.com/traefik/traefik/releases/tag/v3.7.6For more informationIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).SummaryThe ForwardAuth middleware, even when configured with `trustForwardHeader: false`,
  still derives the `X-Forwarded-Port` header sent to the authentication service by
  reading the **attacker-controlled** `X-Forwarded-Proto` header from the original
  incoming request. This allows an unauthenticated remote attacker to cause Traefik
  to forward `X-Forwarded-Port: 443` to the auth service on a plain HTTP connection,
  creating an inconsistency that can bypass port-based authorization checks.DetailsThe fix introduced in commit `5e1de2258` (released as part of the April 2026 security
  advisory GHSA-6384-m2mw-rf54) correctly strips all X-Forwarded-* headers from the
  forwarded auth request when `trustForwardHeader=false`, and reconstructs
  `X-Forwarded-Proto` from the actual TLS state of the connection (`req.TLS`).However, the reconstruction of `X-Forwarded-Port` is delegated to the helper
  `forwardedPort(req)` which receives the **original request** (`req`) rather than
  the sanitized forward request (`forwardReq`):The inconsistency between Proto=http and Port=443 is exploitable against any
  authentication service that gates access based on X-Forwarded-Port.PoCTraefik configuration:Attack:Plain HTTP connection, no TLS – but spoofs port 443
  curl -H "X-Forwarded-Proto: https" http://traefik.example.com/api/admin
  Auth service receives X-Forwarded-Port: 443 → grants accessVerification: Enable Traefik debug logging and observe X-Forwarded-Port: 443
  in the auth request while the connection is plain HTTP.ImpactAny deployment using the ForwardAuth middleware with trustForwardHeader: false where
  the downstream authentication service uses X-Forwarded-Port to make authorization
  decisions is vulnerable to privilege escalation. An unauthenticated attacker can
  bypass port-based security checks (e.g., "only allow requests arriving on HTTPS port
  443") by injecting a single X-Forwarded-Proto: https header on a plain HTTP
  connection.This is a regression of the incomplete fix for GHSA-6384-m2mw-rf54: while the
  X-Forwarded-Prefix and X-Forwarded-Proto spoofing vectors were addressed, the
  X-Forwarded-Port vector was missed.
CVSS v4.0 score: 6.9
CVSS v3.1 score: 5.8