CVE-2026-33433: Authentication Spoofing via Header Canonicalization Bypass in Traefik Middlewares

Traefik operates as a reverse proxy and load balancer, frequently terminating client authentication via its BasicAuth and DigestAuth middlewares. These middlewares validate incoming credentials and pass the authenticated username to backend services using a configured HTTP header, defined by the headerField directive. The backend service relies on this injected header to establish the identity and authorization scope of the incoming request.

CVE-2026-33433 represents an Authentication Bypass by Spoofing (CWE-290) vulnerability located within these authentication middlewares. The flaw manifests exclusively when administrators configure the headerField directive using non-canonical casing, such as x-auth-user instead of X-Auth-User. This configuration state creates a discrepancy between how Traefik writes the header and how downstream applications read it.

An attacker exploiting this vulnerability can inject arbitrary usernames into the request pipeline. By supplying a maliciously crafted HTTP header alongside valid, low-privileged authentication material, the attacker successfully proxies the request while overriding the identity assertion provided by Traefik. The backend service receives the spoofed identity and processes the request under an elevated or distinct authorization context.

The vulnerability is classified with a Medium severity (CVSS 4.0 score of 5.1). The requirements for exploitation—specifically the non-canonical configuration state and the prerequisite of holding valid credentials—limit the widespread exploitability of the flaw. However, within affected configurations, the vulnerability consistently yields a complete authorization bypass for the underlying backend services.

The technical root cause originates from the interaction between Go's internal representation of HTTP headers and the specific mechanism Traefik utilizes to populate the headerField. In the Go standard library (net/http), the Header type is defined as map[string][]string. Standard methods for header manipulation, such as Header.Set(), Header.Get(), and Header.Del(), internally invoke net/textproto.CanonicalMIMEHeaderKey() to normalize header keys to a standardized format (e.g., converting x-auth-user to X-Auth-User).

Vulnerable versions of Traefik bypass this canonicalization process by performing a direct map assignment. When assigning the authenticated username to the request header map, the middleware uses the exact string provided in the headerField configuration. If the administrator specifies x-auth-user, Traefik creates a map entry explicitly keyed as x-auth-user, without applying canonicalization.

This direct assignment creates a vector for HTTP header pollution. If an attacker manually includes the canonicalized header X-Auth-User in their initial HTTP request, Traefik's internal map will contain two distinct entries. The Traefik middleware authenticates the user based on the provided credentials and writes the genuine username to the lowercase x-auth-user key, leaving the attacker's X-Auth-User key unmodified.

When the Go HTTP server finalizes the request and forwards it to the backend service, it serializes both header fields onto the wire. Depending on the HTTP parsing implementation of the backend framework, the duplicate headers are merged or prioritized differently. Most frameworks, including Go's own Header.Get(), prioritize the canonical key. Consequently, the backend application processes the attacker's injected identity rather than the identity validated by Traefik.

The vulnerability exists within the request mutation logic of the authentication middlewares, specifically in pkg/middlewares/auth/basic_auth.go and pkg/middlewares/auth/digest_auth.go. The flaw is a direct consequence of optimizing or overlooking the canonicalization step during header assignment.

The vulnerable implementation performs direct map access on the http.Request.Header object:

// Vulnerable code in basic_auth.go
if b.headerField != "" {
    req.Header[b.headerField] = []string{user}
}

By accessing req.Header as a raw map, the middleware avoids the overhead of the CanonicalMIMEHeaderKey function. However, it also violates the contract expected by the Go HTTP ecosystem, which assumes all map keys in http.Header are properly canonicalized. This allows the attacker's pre-existing, canonicalized header to survive the mutation phase without being overwritten.

The remediation requires replacing the direct map assignment with the standard Header.Set() method. This method enforces canonicalization on the provided key, ensuring that any existing header matching the canonical form is overwritten by the authenticated username.

// Patched code implementation
if b.headerField != "" {
    req.Header.Set(b.headerField, user)
}

With the patched code, if the configuration specifies x-auth-user, the Set() method automatically canonicalizes it to X-Auth-User. If the attacker provided X-Auth-User: admin in the request, the Set() method explicitly overwrites that value with the validated username. The resulting request forwarded to the backend contains exactly one authoritative identity header, eliminating the spoofing vector.

Exploitation of CVE-2026-33433 requires two preconditions: the target Traefik instance must utilize a non-canonical headerField configuration, and the attacker must possess valid authentication material for the middleware. The required credentials do not need elevated privileges; any valid account sufficient to pass the BasicAuth or DigestAuth challenge is adequate.

The target configuration typically resembles the following YAML definition, demonstrating the vulnerable non-canonical headerField directive:

middlewares:
  auth:
    basicAuth:
      users: ["user:$2y$05$..."]
      headerField: "x-auth-user"

To execute the attack, the adversary constructs an HTTP request containing the valid authentication credentials alongside the injected canonical header. The following curl command demonstrates the exploitation technique, supplying the credentials for user while injecting the X-Auth-User header with the value admin.

curl -u user:password -H "X-Auth-User: admin" http://traefik-proxy/secure-endpoint

Upon processing this request, Traefik validates the user:password pair. The middleware then writes user to the x-auth-user map key. The proxy forwards the request to the backend containing both X-Auth-User: admin and x-auth-user: user. The backend application, standardizing the incoming headers, reads the canonical X-Auth-User value and assigns the admin identity to the session, completing the privilege escalation sequence.

The successful exploitation of CVE-2026-33433 results in a complete authorization bypass for the backend services protected by the Traefik proxy. The primary consequence is identity spoofing; the attacker forces the backend application to process requests under an arbitrary user context. The severity of this outcome depends entirely on the authorization model of the downstream service.

If the backend application relies solely on the proxy-injected header for role-based access control (RBAC), the attacker achieves immediate privilege escalation. By injecting the identity of an administrative user, the attacker gains access to restricted endpoints, administrative panels, or sensitive data repositories. The integrity and confidentiality of the backend system are compromised as a direct result of the proxy's failure to sanitize the identity assertion.

The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N) accurately reflects the technical constraints and impact of the vulnerability. The Attack Complexity (AC) and Attack Requirements (AT) are elevated due to the necessity of a specific, non-default configuration state. The Privileges Required (PR) metric is High, as the attacker must hold valid basic or digest authentication credentials to bypass the initial proxy challenge.

Despite the specific prerequisites, the vulnerability carries significant risk for environments utilizing customized proxy configurations. Backend systems operating under the assumption of zero-trust network boundaries frequently rely on reverse proxies to enforce authentication guarantees. This vulnerability breaks that foundational assumption, converting a low-privileged proxy account into a high-privileged application account.

The primary and most effective remediation strategy is to upgrade the Traefik deployment to a patched version. The vendor has addressed the vulnerability in Traefik v2.11.42, v3.6.12, and the early access release v3.7.0-ea.3. These releases implement the standard Header.Set() method, ensuring all identity assertions are properly canonicalized before forwarding requests to backend services.

In environments where immediate patching is not feasible, administrators must apply configuration changes to mitigate the vulnerability. The simplest mitigation involves updating the headerField directive in all BasicAuth and DigestAuth middleware definitions to use Canonical-Casing. Changing x-auth-user to X-Auth-User eliminates the map collision, causing Traefik to correctly overwrite any attacker-supplied headers.

An alternative mitigation involves implementing a secondary middleware to explicitly strip the sensitive header prior to authentication. By chaining a requestHeader middleware before the authentication middleware, administrators can ensure the request environment is sanitized.

middlewares:
  strip-auth-header:
    headers:
      customRequestHeaders:
        X-Auth-User: ""

Security engineers should also review proxy access logs for evidence of attempted exploitation. Detection strategies should focus on identifying HTTP requests that contain multiple variations of the same authentication header, specifically instances where both canonical and non-canonical forms are present simultaneously.