CVE-2026-88011: Traefik: ForwardAuth identity spoofing via dot-form header alias
Summary
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, XAuthUser 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.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.56 - https://github.com/traefik/traefik/releases/tag/v3.7.12
For more information
If you have any questions or comments about this advisory, please open an issue.
<details> <summary>Original Description</summary>
Summary 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 HTTPXAUTHENTICATEDUSER 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.
Details At v3.7.10, pkg/server/serverentrypointtcp.go:800-818 removes or rejects only names containing . After successful authentication, pkg/middlewares/auth/forward.go:314-326 deletes and replaces only the canonical authResponseHeaders key. The dot alias remains in req.Header and the standard reverse proxy forwards both legal field names.
Go's HTTP/1 writer sorts header names lexically, placing X-Authenticated-User before X.Authenticated.User. PHP then collapses both into one $SERVER key, so the attacker value deterministically wins.
This is an incomplete-fix sibling of GHSA-x677-9fxg-v5c5: the published underscore input is blocked by the new entry-point strategy, while the dot input bypasses that mitigation on the current stable release.
PoC traefik-dot-forwardauth-poc.zip
run: bash docker compose up -d bash verify.sh docker compose down
The decisive request is:
http GET /probe HTTP/1.1 Host: 127.0.0.1:18080 X.Authenticated.User: admin Connection: close
Expected backend identity: lab-user, as returned by ForwardAuth.
Observed on v3.7.10: admin.
The script also verifies that requests without the alias, with the canonical header, and with the already-fixed underscore alias all produce lab-user.
Impact Applications that authorize requests using a ForwardAuth-provided identity header can receive an attacker-selected username or role instead. This was runtime-verified with PHP 8.2.27 and 8.2.33; impact on other normalization-prone backends is conditional. A lower-privilege permitted client may consequently impersonate another user or administrative role, affecting confidentiality and integrity.
This report does not claim bypass of a ForwardAuth denial: the auth service must first permit the request.
</details> ---
Other sources
Traefik is an open source HTTP reverse proxy and load balancer. Prior to 2.11.56, and from 3.0.0 until 3.7.12, a client-supplied dot-form header such as X.Authenticated.User survives ForwardAuth replacement and underscoreHeadersStrategy because Go treats it as distinct from X-Authenticated-User while normalization-prone CGI, WSGI, PHP, and NGINX backends collapse both names. A backend can consequently consume the client value instead of the identity Traefik asserted, allowing identity spoofing for any header managed by Traefik. The aliasHeadersStrategy protection is disabled by default and must be configured as delete or reject. The mitigation is available in 2.11.56 and 3.7.12.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/traefik/traefik/v3to a version that resolves this vulnerability.Fixed in 3.7.12 - Upgrade
Upgrade
go/github.com/traefik/traefik/v2to a version that resolves this vulnerability.Fixed in 2.11.56 - Upgrade
Upgrade
traefik/traefikto a version that resolves this vulnerability.Fixed in 2.11.56 - Upgrade
Upgrade
traefik/traefikto a version that resolves this vulnerability.Fixed in 3.7.12 - Configuration
Set the Traefik entry point option aliasHeadersStrategy to "delete" (the mitigation is available in 2.11.56 and 3.7.12; the default "keep" preserves vulnerable behavior and the option must be explicitly set to delete or reject).
Traefik entry point aliasHeadersStrategy = delete - Configuration
Alternatively, set the Traefik entry point option aliasHeadersStrategy to "reject" (the mitigation is available in 2.11.56 and 3.7.12; the default "keep" preserves vulnerable behavior and the option must be explicitly set to delete or reject).
Traefik entry point aliasHeadersStrategy = reject
Event History
Frequently Asked Questions
Which deployments are realistically exposed to identity spoofing?
Deployments are exposed when Traefik uses ForwardAuth to manage identity headers and the upstream backend normalizes dot-form and hyphen-form header names, as CGI, WSGI, PHP, and NGINX backends can. Any header managed by Traefik can be spoofed in this scenario.
What must an attacker be able to do?
An attacker must be able to send a client-supplied dot-form header alias, such as X.Authenticated.User, to Traefik. If the backend collapses that name with Traefik's X-Authenticated-User header, it may consume the attacker-controlled value instead of the identity asserted by Traefik.
Are default configurations affected?
Yes. The aliasHeadersStrategy protection is disabled by default, so dot-form aliases are not deleted or rejected unless this strategy is explicitly configured.
What can be done if upgrading is not immediately possible?
Configure aliasHeadersStrategy to delete or reject. This prevents the dot-form aliases that enable the header-name collision.
How can I determine whether an instance needs remediation?
Remediation is needed for Traefik versions before 2.11.56, or versions from 3.0.0 through 3.7.11, when ForwardAuth-managed headers are sent to a normalization-prone backend. Versions 2.11.56 and 3.7.12 include the mitigation.