CVE-2026-33433
HTTP Header Injection in Traefik Enables Identity Impersonation
Publication date: 2026-03-27
Last updated on: 2026-04-03
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| traefik | traefik | 3.7.0 |
| traefik | traefik | to 2.11.42 (exc) |
| traefik | traefik | 3.7.0 |
| traefik | traefik | From 3.0.0 (inc) to 3.6.12 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-290 | This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
CVE-2026-33433 allows an authenticated attacker to impersonate any user identity to backend services by injecting a canonical HTTP header that overrides Traefik's non-canonical header. This impersonation can lead to unauthorized access or actions on backend systems.
Such unauthorized access and identity spoofing can compromise the integrity and confidentiality of sensitive data, which are critical requirements under common standards and regulations like GDPR and HIPAA.
Therefore, if exploited, this vulnerability could lead to non-compliance with these regulations by enabling unauthorized data access or manipulation, potentially resulting in data breaches or violations of access control policies.
Can you explain this vulnerability to me?
CVE-2026-33433 is a moderate severity vulnerability in Traefik's BasicAuth and DigestAuth middlewares that occurs when the `headerField` configuration uses a non-canonical HTTP header name (for example, "x-auth-user" instead of "X-Auth-User").
Traefik writes the authenticated username into HTTP request headers using a non-canonical key, which creates a separate header entry rather than overwriting any existing canonical header. Because Go’s HTTP header map keys headers by their canonical names, the non-canonical and canonical headers are treated as distinct.
An authenticated attacker with valid credentials can inject the canonical header (e.g., "X-Auth-User: superadmin") alongside Traefik’s non-canonical header. Backend frameworks typically prioritize the canonical header, so they read the attacker-controlled value first, allowing the attacker to impersonate any user identity to the backend.
The root cause is that Traefik directly assigns the header map without canonicalizing the header key or removing pre-existing headers, which leads to this spoofing issue.
How can this vulnerability impact me? :
This vulnerability allows an authenticated attacker with valid credentials, even if low-privilege, to escalate their privileges by impersonating any user identity to backend services that rely on the `headerField` header for authorization.
By injecting a canonical header with a privileged identity, the attacker can gain unauthorized access or perform unauthorized actions on backend systems.
The impact on the vulnerable system itself in terms of confidentiality, integrity, and availability is none, but the subsequent impact on confidentiality and integrity is high due to the impersonation capability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by inspecting HTTP headers in requests passing through Traefik, specifically looking for cases where both a non-canonical and a canonical version of the same authentication header are present. An attacker injects a canonical header (e.g., "X-Auth-User") alongside Traefik's non-canonical header (e.g., "x-auth-user"), which can be identified by analyzing HTTP traffic.
To detect this on your system or network, you can capture and analyze HTTP requests to your backend services behind Traefik. Look for requests containing duplicate authentication headers where one is canonical and the other is non-canonical.
Suggested commands include using tools like tcpdump or tshark to capture HTTP traffic, and grep or similar tools to filter headers:
- Capture HTTP traffic on the relevant interface: tcpdump -i <interface> -A -s 0 'tcp port 80 or tcp port 443'
- Use tshark to filter HTTP headers containing authentication fields: tshark -Y 'http.header contains "auth-user"' -T fields -e http.header
- Search logs or captured requests for both "x-auth-user" and "X-Auth-User" headers appearing together.
Additionally, reviewing Traefik configuration files for usage of non-canonical headerField values (e.g., "x-auth-user" instead of "X-Auth-User") can help identify vulnerable setups.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation steps are to upgrade Traefik to a patched version where this vulnerability is fixed. The fixed versions are 2.11.42, 3.6.12, and 3.7.0-ea.3 or later.
If upgrading immediately is not possible, ensure that the Traefik configuration uses canonical HTTP header names for the headerField setting (e.g., "X-Auth-User" instead of "x-auth-user") to prevent the injection of attacker-controlled headers.
The vulnerability is caused by Traefik writing headers using non-canonical keys without removing existing headers, so configuring headerField with canonical casing and avoiding non-canonical header names reduces risk.
Also, consider implementing additional backend validation to reject requests with duplicate or conflicting authentication headers.
Finally, monitor for suspicious authentication header patterns in your logs and network traffic as a temporary detection measure.