| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/traefik/traefik | all versions | |
| github.com/traefik/traefik/v2 | ≥ 2.11.9, < 2.11.38 | 2.11.38 |
| github.com/traefik/traefik/v3 | ≥ 3.1.3, < 3.6.9 | 3.6.9 |
| traefik | ≥ 2.11.9, < 2.11.38≥ 3.1.3, < 3.6.9 | 2.11.383.6.9 |
There is a potential vulnerability in Traefik managing the Connection header with X-Forwarded headers.
When Traefik processes HTTP/1.1 requests, the protection put in place to prevent the removal of Traefik-managed X-Forwarded headers (such as X-Real-Ip, X-Forwarded-Host, X-Forwarded-Port, etc.) via the Connection header does not handle case sensitivity correctly. The Connection tokens are compared case-sensitively against the protected header names, but the actual header deletion operates case-insensitively. As a result, a remote unauthenticated client can use lowercase Connection tokens (e.g. Connection: x-real-ip) to bypass the protection and trigger the removal of Traefik-managed forwarded identity headers.
This is a bypass of the fix for CVE-2024-45410.
Depending on the deployment, the impact may be higher if downstream services rely on these headers (such as X-Real-Ip or X-Forwarded-*) for authentication, authorization, routing, or scheme decisions.
No workaround available.
If there are any questions or comments about this advisory, please open an issue.
Traefik's XForwarded middleware (removeConnectionHeaders) tries to prevent clients from using the Connection header to strip trusted X-Forwarded-* headers, but the protection compares the Connection tokens case-sensitively while the deletion is case-insensitive.
As a result, a remote unauthenticated client can send a lowercase token like Connection: x-real-ip and still trigger deletion of traefik-managed X-Real-Ip (and similarly named headers in the managed list).
This can cause downstream routing, scheme, and header-based authn/authz decisions to be evaluated with missing trusted forwarding identity headers.
CRITICAL
</details>Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeRationale: the PoC demonstrates an end-to-end access control bypass pattern when a downstream service uses proxy-provided identity headers (for example, X-Real-Ip) for IP allowlists or trust decisions. A remote unauthenticated client can strip the traefik-managed identity header via a lowercase Connection token, causing the downstream service to evaluate the request without the expected header signal.
removeConnectionHeaders uses a case-sensitive membership check for protected header names when inspecting Connection tokens, but it deletes headers via net/http which treats header names case-insensitively. A lowercase token bypasses the protection check and still triggers deletion.
Remote unauthenticated HTTP client (untrusted IP) sends Connection: x-real-ip, and Traefik deletes the generated X-Real-Ip header.
The attached poc.zip contains a deterministic, make-based integration PoC with a canonical run and a negative control.
Canonical (vulnerable):
unzip poc.zip -d poc
cd poc
make test
Output contains:
[CALLSITE_HIT]: pkg/middlewares/forwardedheaders/forwarded_header.go:225
[PROOF_MARKER]: downstream_admin_bypass=1 x_real_ip_present=0
Control (same env, no lowercase token):
unzip poc.zip -d poc
cd poc
make test
Output contains:
[CALLSITE_HIT]: pkg/middlewares/forwardedheaders/forwarded_header.go:225
[NC_MARKER]: downstream_admin_bypass=0 x_real_ip_present=1
Expected: Connection tokens are handled case-insensitively and protected identity headers (for example, X-Real-Ip and X-Forwarded-*) are not deleted due to client-supplied Connection options (regardless of token casing).
Actual: Lowercase Connection tokens bypass the protection check and still trigger deletion of traefik-managed identity headers (for example, X-Real-Ip).
Fix accepted when: a request with Connection: x-real-ip does not cause deletion of traefik-managed X-Real-Ip, and a regression test covers this behavior.