CVE-2026-88011: Traefik: ForwardAuth identity spoofing via dot-form header alias

There is a medium severity vulnerability in Traefik’s handling of request headers whose name aliases another header name. Go canonicalizes header names on dashes only, so X-Auth-User, X_Auth_User and X.Auth.User are three distinct headers to Traefik, while backends that derive variable names from header names (CGI, WSGI, PHP, NGINX, and others) collapse all of them into the same variable. A client can therefore smuggle an alias of a header that Traefik manages past the middleware managing it — for example a dot-form X.Authenticated.User alongside the canonical X-Authenticated-User written by the ForwardAuth middleware — and have such a backend read the client-supplied value instead of the identity Traefik asserted. Any header Traefik sets is exposed, not only ForwardAuth’s. This is an incomplete-fix sibling of GHSA-x677-9fxg-v5c5, which blocked only the underscore form.

The mitigation is the new aliasHeadersStrategy entry point option. It defaults to keep, which preserves the previous behavior for backwards compatibility, so it must be explicitly set to delete or reject to take effect.

Traefik v1.x, the v2 releases up to v2.11.55 and the v3 releases from v3.0.0 to v3.7.11 are affected. The unmaintained lines among them will not receive a patch of their own, and the remedy for their users is to upgrade to v2.11.56 or v3.7.12 and set aliasHeadersStrategy.

Traefik’s ForwardAuth middleware removes the configured canonical identity header before copying the value returned by the auth service. However, a client-supplied dot-form alias such as X.Authenticated.User survives both this replacement and underscoreHeadersStrategy: delete.

The tested PHP 8.2 built-in SAPI maps X-Authenticated-User and X.Authenticated.User to the same HTTP_X_AUTHENTICATED_USER server variable. In Traefik’s tested HTTP/1 backend path, the client value is serialized last and overrides the identity asserted by ForwardAuth.

A client whom ForwardAuth permits as a lower-privilege identity can therefore be treated by the backend as another user or role.