CVE-2026-88011 in Traefik
Summary
by MITRE • 09/10/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
Traefik, a widely deployed open-source HTTP reverse proxy and load balancer, contains a critical identity spoofing vulnerability affecting versions prior to 2.11.56 and from version 3.0.0 through 3.7.12. This flaw stems from an inconsistency in how Traefik normalizes HTTP header names compared to the normalization logic employed by common backend application frameworks such as CGI, WSGI, PHP, and NGINX. Specifically, when a client supplies a dot-formatted header name, for example X.Authenticated.User, Go’s standard library treats this string as distinct from its hyphenated equivalent, X-Authenticated-User. However, many popular web server configurations and backend frameworks automatically collapse or normalize these variations into a single canonical form during request processing. This discrepancy creates a divergence between the identity asserted by Traefik via its ForwardAuth middleware and the actual value consumed by the downstream application.
The operational impact of this vulnerability is severe, as it allows an attacker to bypass authentication controls through header manipulation. In typical deployments using the ForwardAuth feature, Traefik validates credentials with an external auth service and then injects a specific header into the request sent to the backend to indicate the authenticated user identity. Due to the normalization mismatch described above, if an attacker sends a request containing both the dot-formatted version of the target header (e.g., X.Authenticated.User) set to a malicious value, and relies on Traefik’s injected hyphenated version for legitimate authentication checks, the backend may prioritize or accept the client-supplied dot-formatted value. Consequently, the application perceives the attacker as an authenticated user with elevated privileges, effectively allowing identity spoofing across any header managed by Traefik that is subject to this normalization behavior. This undermines the integrity of access control mechanisms and can lead to unauthorized data exposure or administrative privilege escalation depending on the backend’s implementation.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as it involves bypassing authentication logic through input manipulation, and CWE-693 Protection Mechanism Failure, specifically regarding the failure of header normalization strategies to prevent spoofing. In terms of MITRE ATT&CK tactics, this flaw facilitates Initial Access via T1078 Valid Accounts or T1552 Unsecured Credentials if combined with other vectors, but primarily represents a mechanism bypass that allows an attacker to assume valid identities without proper credential validation. The root cause lies in the lack of strict enforcement of header name canonicalization within Traefik’s proxy layer relative to its backend counterparts.
The recommended mitigation is to upgrade to version 2.11.56 or later, or version 3.7.12 and above, where this normalization inconsistency has been addressed. For environments that cannot immediately patch due to operational constraints, administrators should configure the aliasHeadersStrategy setting explicitly. By default, this protection may be disabled; therefore, it is critical to set the strategy to either delete or reject for any headers involved in authentication flows. This ensures that conflicting header variants are removed from the request before it reaches the backend, preventing the application from accepting spoofed values derived from client-supplied dot-formatted headers. Regular auditing of proxy configurations against evolving normalization standards across different web server technologies is also advised to maintain robust identity integrity.