CVE-2026-88879
HighCVSS 8.2Exploitation Probability (EPSS)
Low risk20th percentile - higher than 20% of all known CVEs
Summary
Traefik v1.x, v2.x through v2.11.55, and v3.0.0 through v3.7.11 canonicalize header names only on dashes, so X-Auth-User, X_Auth_User, and X.Auth.User are treated as three distinct headers by Traefik, while backends that derive variable names from header names (CGI, WSGI, PHP, NGINX, and others) collapse them into a single variable. A client can smuggle a dot-form alias of a header managed by Traefik alongside the canonical version, e.g., X.Authenticated.User alongside X-Authenticated-User, causing the backend to read the client-supplied value instead of the identity Traefik asserted.
Risk Assessment
A client admitted by ForwardAuth as a low-privilege identity can be treated by the backend as a different user or role, leading to privilege escalation and access control bypass. Any header Traefik sets is affected, not only ForwardAuth's.
Recommendation
Upgrade Traefik to v2.11.56 or v3.7.12 and explicitly set the aliasHeadersStrategy option to 'delete' or 'reject' (the default 'keep' does not provide protection). Note that unmaintained release lines will not receive a patch.
Other vulnerabilities in Traefik
See all- CVE-2026-88008Critical
Traefik is an open source HTTP reverse proxy and load balancer. From 2.11.26 until 2.11.57 and 3.7.13, Traefik forwards a client-supplied Connection header requesting Upgrade, the Upgrade: h2c token, and HTTP2-Settings to a shared backend. If the backend accepts h2c and returns 101 Switching Protocols, Traefik enters a raw tunnel and no longer applies routers, BasicAuth, ForwardAuth, IPAllowList, RateLimit, access logging, metrics, or tracing to later HTTP/2 requests, allowing an unauthenticated request through an unprotected route to reach protected paths on the same backend. This issue is fixed in 2.11.57 and 3.7.13.
- CVE-2026-88007Critical
Traefik (open source HTTP reverse proxy and load balancer) from 2.11.0 until 2.11.57 and 3.7.13 has an HTTP/3 issue: ConnContext does not call service.AddTransportOnContext, so kerberosRoundTripper uses a shared backend transport instead of one dedicated to each frontend connection. With HTTP/3 enabled, a backend using connection-bound NTLM or Negotiate authentication, and backend keep-alive, an unrelated client can reuse a backend connection authenticated for a victim, read victim-only data, and act as that victim without the victim credentials.
- CVE-2026-88877Critical
Traefik (HTTP reverse proxy and load balancer) in versions >= v3.7.0 and <= v3.7.11 has a flaw in the Kubernetes ingress-nginx provider for Ingresses carrying both an authentication annotation and the nginx.ingress.kubernetes.io/from-to-www-redirect annotation. The provider creates an additional 'sibling' router that matches on the host alone, carries only the RedirectRegex middleware, and still points at the parent router's protected backend service. Because RedirectRegex is not a terminal handler, a request its pattern does not match is forwarded to the backend, and because the redirect pattern only accepts a numeric port, a request with a non-numeric or empty port (e.g. 'Host: www.example.com:x') selects the sibling router, misses the redirect, and is proxied to the protected backend with none of the Ingress's annotation-derived middlewares applied. This discards not only authentication (e.g. BasicAuth) but every annotation-derived middleware, including source-IP allowlisting. Traefik v2 and v3 releases before v3.7.0 are not affected. The issue is fixed in v3.7.12.
- CVE-2026-85597Critical
Traefik before v2.11.55 and v3.0.0 through v3.7.10 contain a TLS option conflict resolution vulnerability that allows unauthenticated attackers to bypass client-certificate authentication by creating conflicting TLS options on multi-host routers. Attackers can reach protected backends by exploiting shared TLS resolution across multiple hostnames in a single router rule, causing the strict mTLS requirement to fall back to default options for all hosts.
- CVE-2026-85596Critical
Traefik versions >= v3.7.0 and <= v3.7.10 contain an authentication bypass in the Kubernetes Ingress NGINX provider. The TLS option generated for an Ingress carrying the nginx.ingress.kubernetes.io/auth-tls-secret annotation was named after the Ingress namespace and name. As a result, two Ingress objects sharing the same host, the same client CA secret, and the same client-authentication mode produced two distinct TLS option names for that host. Traefik treats this as a TLS options conflict and falls back to the entry point's default TLS configuration, which does not request a client certificate, so a route configured with nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" becomes reachable without a client certificate. Only the v3.7 line is affected; the issue is fixed in v3.7.11.
- CVE-2026-85595Critical
Traefik versions before v2.11.55 and versions v3.0.0 through v3.7.10 contain an authentication bypass vulnerability in the digestAuth middleware where unknown usernames receive an empty secret instead of rejection. Attackers can compute a valid digest response using the empty secret and arbitrary credentials to bypass authentication on any digestAuth-protected route without a valid username or password.
- CVE-2026-85594Critical
Traefik versions from v3.7.1 fail to enforce crossProviderNamespaces restrictions on the traefik.ingress.kubernetes.io/service.middlewares Service annotation in the Kubernetes Ingress provider. A namespace-limited tenant excluded from the allowlist can attach an operator-owned middleware to its Service, and if that middleware injects backend credentials, recover them at a controlled backend.
- CVE-2026-71324Critical
Vulnerability in Traefik (before 2.11.53, 3.6.24, and 3.7.9) in the default HTTP reverse proxy. Forwarding CONNECT requests can lead to connection desynchronization, allowing an attacker to smuggle responses to another client.
- CVE-2026-54763Critical
In Traefik prior to versions v2.11.51, v3.6.22, and v3.7.6, the BasicAuth, DigestAuth, and ForwardAuth middlewares fail to strip underscore-variant identity headers that backends normalize to dashed forms. An attacker can inject such a header to spoof identity or bypass authorization.
- CVE-2026-53622Critical
Traefik versions prior to 3.7.3, 3.6.18, and 2.11.51 have a critical vulnerability in HTTP/3 (QUIC) TLS configuration selection that allows unauthenticated clients to bypass router-specific mTLS enforcement. When HTTP/3 is enabled, the TLS handshake selects the TLS configuration via exact, case-sensitive SNI lookup, failing to match wildcard host patterns or case variants. This allows clients to complete the QUIC handshake without presenting a certificate, while the HTTP routing layer still dispatches requests to protected backends.
Original NVD description (English source)
Traefik is an HTTP reverse proxy and load balancer. In Traefik v1.x, v2.x through v2.11.55, and v3.0.0 through v3.7.11, header names are canonicalized only on dashes, so X-Auth-User, X_Auth_User and X.Auth.User are treated as three distinct headers by Traefik, while backends that derive variable names from header names (CGI, WSGI, PHP, NGINX and others) collapse them into a single variable. A client can therefore smuggle a dot-form alias of a header that Traefik manages past the middleware managing it — for example supplying X.Authenticated.User alongside the canonical X-Authenticated-User written by the ForwardAuth middleware — causing such a backend to read the client-supplied value instead of the identity Traefik asserted. In the tested configuration (PHP 8.2 built-in SAPI over an HTTP/1 backend path), Go's lexical header ordering makes the attacker-supplied value win deterministically, so a client that ForwardAuth admits as a low-privilege identity can be treated by the backend as a different user or role. Any header Traefik sets is affected, not only ForwardAuth's. This is an incomplete fix for GHSA-x677-9fxg-v5c5, which blocked only the underscore form. Fixed in v2.11.56 and v3.7.12, which add the aliasHeadersStrategy entry-point option; because it defaults to 'keep' for backwards compatibility, it must be explicitly set to 'delete' or 'reject' for the fix to take effect. Unmaintained release lines will not receive a patch.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

