CVE-2026-54763 in Traefik: When a Stripped Header Still Reaches the Backend

A reverse proxy strips the headers that would spoof an authenticated identity, and then the header it believed it stripped arrives at the backend anyway. That is CVE-2026-54763. The cause is an asymmetry in how hyphens and underscores are normalised, the kind of thing you cannot spot unless you already know about it. Here are the facts as verified from primary sources, and how to check your own environment.

At a glance

What happens: the asymmetry between hyphens and underscores

The official description reads:

The problem lives where three facts overlap.

1. The proxy stripped headers by their canonical form. Before writing the authenticated identity into its own header, Traefik deletes any same-named header the client sent. But Go's header deletion normalises case and hyphens only; the underscore is not treated as a separator. The hyphenated spelling disappears while its underscore-spelled sibling survives.
2. Backends do not distinguish hyphens from underscores. CGI-style interfaces build a meta-variable name by upper-casing the header name, replacing hyphens with underscores and prefixing HTTP_. The hyphen and underscore spellings therefore become the same name as seen by the backend.
3. What the proxy believed it removed reaches the backend. The surviving underscore variant arrives alongside the value Traefik intended to set, or, on the ForwardAuth authResponseHeaders path, instead of it. The application then reads it as if it were the trusted header.

The backend's normalisation rule, from primary sources

Treating hyphens and underscores alike is not an implementation quirk but a documented transformation. RFC 3875 (CGI 1.1), section 4.1.18, states:

The PHP manual entry for $_SERVER says the same thing:

After this transformation the hyphen and underscore spellings become exactly the same key. If the proxy removed only one of them, the backend reads whichever one survived.

Why nginx has underscores_in_headers

This is not a newly discovered class of problem; it is a known landmine in the reverse proxy world, and nginx has a setting for exactly this. The official documentation (ngx_http_core_module) says:

• Syntax: underscores_in_headers on | off;
• Default: underscores_in_headers off;
• Context: http, server

The default of off is itself a design-level answer to this risk. Read the detail carefully, though. With off, nginx does not simply delete such headers; it marks them invalid, and what happens next is governed by the ignore_invalid_headers directive. Saying "nginx drops underscore headers by default" is close in outcome but inaccurate as a description of the mechanism.

The fix, and the part that needs attention

The fixed versions are v2.11.51, v3.6.22 and v3.7.6. The v3.6.22 release notes name this CVE among the issues fixed.

On there being two scores

This CVE carries two scores of quite different character. Quoting only one of them changes the impression substantially, so cite each with its source.

The 10.0 comes from Scope being rated Changed (S:C) in the CVSS 3.1 vector, which directly reflects the nature of the flaw: it crosses the proxy boundary and corrupts a decision made on the other side.

The SSVC decision recorded by CISA Coordinator on 8 July 2026 was exploitation: none, automatable: yes, technicalImpact: partial. Searching the 3 August 2026 CISA KEV catalog, this CVE is not listed.

How to check your own environment

All of these are checks against an environment you own.

1. Determine the Traefik version. Inspect the running binary or the container image tag.

   # Binary
   traefik version
   
   # Container (check both the image tag and the version inside)
   docker ps --format '{{.Image}}'
   docker exec <container> traefik version

   Image tags and actual versions can disagree, so judge by the running version, not the tag.
2. Check whether you use an affected middleware. Look for basicAuth, digestAuth or forwardAuth in your dynamic configuration, and whether they are configured to pass the authenticated identity to the backend (an option naming a header, or ForwardAuth's authResponseHeaders). If no identity is passed downstream, this path is not exposed.
3. Check whether the backend equates hyphens and underscores. Anything going through PHP, CGI or FastCGI does, by the RFC 3875 rule above. Some application frameworks apply their own normalisation, so confirm the actual behaviour in the backend implementation.
4. Check the entry point configuration. After upgrading, confirm that you explicitly set underscoreHeadersStrategy on the relevant entry points. If you did not, it remains keep, the previous behaviour.
5. If nginx sits in front, check its setting. Has underscores_in_headers been explicitly turned on? Configurations sometimes carry an old on added because "our custom underscore header was not reaching the backend".

Generalising: where to suspect a normalisation mismatch

This defect is less a Traefik-specific mistake than a structural problem: the definition of normalisation changes at every boundary you cross. The same shape of trap hides in places like these.

• Case sensitivity. HTTP header names are case-insensitive, but code that handles them by hand tends to make them case-sensitive. That is exactly CWE-178 here.
• Separator equivalence. Hyphen versus underscore, space versus plus, duplicated slashes.
• Unicode normalisation. Characters that look identical but differ in code points. Are you normalising before comparing?
• Percent-decoding depth. Which layer decodes, and how many times.
• Path comparison including trailing slashes and case. Especially where access control is done on path strings.

The countermeasure always takes one shape. Whoever does the stripping should think in allow lists, not deny lists. Design for "only headers approved for the backend get through" rather than "dangerous headers get removed", and missing one spelling variant no longer breaks the model. The reject option newly added to Traefik behaves close to that idea.