Live › vulnerability › CVE-2026-33433
When Traefik's Basic or Digest auth middleware uses a non-canonical headerField name, a user with valid credentials can send a canonical version of that header and the backend reads the attacker's value. The attacker gets to impersonate any other identity the backend trusts, such as an admin.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-04 03:16 UTC, 1h before NVD. All times on this page are UTC.
Exposure requires Traefik to front a backend that trusts the header set by headerField, and a headerField configured with non-canonical casing such as lowercase. Attackers also need valid credentials for the basic or digest auth middleware, though any such user (even low-privilege) can impersonate others. Deployments that use canonical header casing like X-Auth-User, or that do not rely on the header for authorization, are not affected by the sources' description.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| github.com/traefik/traefik/v2 | go | < 2.11.42 | 2.11.42 |
| github.com/traefik/traefik/v3 | go | >= 3.0.0-beta1, < 3.6.11 | 3.6.12 |
| github.com/traefik/traefik/v3 | go | >= 3.7.0-ea.1, < 3.7.0-ea.3 | 3.7.0-ea.3 |
| traefik | vendor | < 2.11.42 | 2.11.42 |
| traefik | vendor | >= 3.0.0, < 3.6.12 | 3.6.12 |
| traefik | vendor | = 3.7.0 | – |
headerField under basicAuth or digestAuth in Traefik configuration (YAML, Docker labels, or REST API) and check whether its value contains lowercase letters, such as x-auth-user.traefik version; the sources list 2.11.42, 3.6.12, and 3.7.0-ea.3 as fixed.2.11.42.3.6.12.3.7.0-ea.3.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
There is a potential vulnerability in Traefik's Basic and Digest authentication middlewares when headerField is configured with a non-canonical HTTP header name.
An authenticated attacker with valid credentials can inject the canonical version of the configured header to impersonate any identity to the backend. Because Traefik writes the authenticated username using a non-canonical map key, it creates a separate header entry rather than overwriting the attacker's canonical one — causing most backend frameworks to read the attacker-controlled value instead.
If there are any questions or comments about this advisory, please open an issue.
When headerField is configured with a non-canonical HTTP header name (e.g., x-auth-user instead of X-Auth-User), an authenticated attacker can inject a canonical version of that header to impersonate any identity to the backend. The backend receives two header entries — the attacker-injected canonical one is read first, overriding Traefik's non-canonical write.
Tested on Traefik v3.6.10.
At pkg/middlewares/auth/basic_auth.go:92, the authenticated username is written using direct map assignment:
req.Header[b.headerField] = []string{user}
Go's http.Header map is keyed by canonical names (e.g., X-Auth-User). Direct assignment with a non-canonical key (x-auth-user) creates a separate map entry from any canonical-key entry already present. The attacker's X-Auth-User: superadmin occupies the canonical slot and is never overwritten by Traefik's non-canonical write.
The same bug exists in pkg/middlewares/auth/digest_auth.go:100. Notably, forward.go:254 correctly uses http.CanonicalHeaderKey(), showing the fix pattern already exists in the codebase.
Traefik config (YAML, Docker labels, or REST API):
middlewares:
auth:
basicAuth:
users: ["admin:$2y$05$..."]
headerField: "x-auth-user"
Normal request (baseline):
curl -u admin:admin http://traefik/secure/test
# Backend receives: x-auth-user: admin
# Identity = admin ✓
Attack request:
curl -u admin:admin -H "X-Auth-User: superadmin" http://traefik/secure/test
# Backend receives BOTH headers:
# X-Auth-User: superadmin ← attacker-injected (canonical key, read first by most frameworks)
# x-auth-user: admin ← Traefik-set (non-canonical, ignored by most frameworks)
# Identity seen by backend = superadmin ✗
Control test — when headerField uses canonical casing (X-Auth-User), the attack fails. Traefik's write correctly overwrites the attacker's header.
This is realistic because YAML conventions favor lowercase keys, Traefik docs don't warn about canonicalization, and the pattern of backends trusting the headerField header is recommended in Traefik's own documentation.
Fix suggestion:
// basic_auth.go:92 and digest_auth.go:100 — change:
req.Header[b.headerField] = []string{user}
// to:
req.Header.Set(b.headerField, user)
Also strip any incoming headerField header before the auth check with req.Header.Del(b.headerField).
An authenticated attacker with valid credentials (even low-privilege) can impersonate any other user identity to backend services. If backends use the headerField header for authorization decisions (which is the intended use case per Traefik docs), this enables privilege escalation — e.g., a regular user impersonating an admin.
The attack requires the operator to configure headerField with a non-canonical header name, which is the natural thing to do in YAML and is not warned against in documentation.
This page as .md · .json · in your agent: get_signal("CVE-2026-33433")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.