GHSA-6384-m2mw-rf54

Summary

ForwardAuth with trustForwardHeader=false still forwards an attacker-controlled X-Forwarded-Prefix header to the authentication service when Traefik is deployed behind a trusted upstream proxy. If the auth service relies on X-Forwarded-Prefix for authorization or routing decisions, an external attacker can bypass access controls and reach protected backend routes.

This was validated this against Traefik v3.6.12 using the official Docker image and a minimal local Docker setup. A direct request to Traefik is correctly rejected, but the same request succeeds when sent through a trusted reverse proxy, which shows the issue is in the ForwardAuth subrequest handling rather than general ingress header stripping.

Details

The vulnerable behavior comes from the way Traefik builds the subrequest sent to the forward-auth server.

In pkg/middlewares/auth/forward.go, writeHeader first copies all incoming request headers into the auth subrequest:

It then selectively rebuilds only a subset of forwarded headers when trustForwardHeader=false, for example:

• X-Forwarded-For
• X-Forwarded-Method
• X-Forwarded-Proto
• X-Forwarded-Port
• X-Forwarded-Host
• X-Forwarded-Uri

However, it does not remove or rebuild X-Forwarded-Prefix, so an attacker-supplied value remains in the auth request even when forwarded headers are supposed to be untrusted.

This becomes security-relevant when StripPrefix is used before ForwardAuth. In pkg/middlewares/stripprefix/strip_prefix.go, Traefik appends the stripped prefix using Header.Add:

If the attacker already sent X-Forwarded-Prefix: /admin, and StripPrefix later adds /forbidden, the auth service receives both values in this order:

1. /admin (attacker-controlled)
2. /forbidden (Traefik-generated)

An auth service that uses the first X-Forwarded-Prefix value can therefore be tricked into authorizing a protected route.

Why this appears unintended:

• The docs say trustForwardHeader means "Trust all X-Forwarded-* headers" and defaults to false.
• The migration notes say X-Forwarded-Prefix is handled like other X-Forwarded-* headers and removed from untrusted sources.
• The direct-to-Traefik test case behaves consistently with that expectation and returns 403.
• Only the auth subrequest path still honors the spoofed X-Forwarded-Prefix.

Relevant source/documentation locations:

• pkg/middlewares/auth/forward.go lines 393-459
• pkg/middlewares/stripprefix/strip_prefix.go lines 65-68
• pkg/middlewares/forwardedheaders/forwarded_header.go lines 15-43
• docs/content/reference/routing-configuration/http/middlewares/forwardauth.md lines 59-62 and 130-140
• docs/content/migrate/v3.md lines 192-196

This was only tested and validated with X-Forwarded-Prefix. By source review, other forwarded headers that are copied but not rebuilt in writeHeader may deserve separate review, but I am not claiming impact for them here.

PoC

The following uses the official traefik:v3.6.12 Docker image and a mounted traefik.toml, matching the documented deployment style.

1. Create traefik.toml:

2. Create dynamic.toml:

3. Create auth.py:

4. Create frontend.conf:

5. Start the containers:

6. Send three requests:

Direct to Traefik, spoofed header:

Expected result:

Through trusted proxy, no spoofing:

Expected result:

Through trusted proxy, spoofed header:

Observed result:

The backend response confirms that the request reached the protected upstream after the auth service accepted the attacker-controlled prefix.

7. Optional log confirmation from the auth service:

Observed log sequence:

8. Cleanup:

Impact

This is an authentication bypass / trust-boundary bypass.

Affected deployments are those that:

• run Traefik behind a trusted upstream proxy
• use ForwardAuth
• rely on trustForwardHeader=false to avoid trusting client-supplied forwarded headers
• pass X-Forwarded-Prefix to the auth service, which happens by default when authRequestHeaders is empty
• make authorization or routing decisions based on X-Forwarded-Prefix, especially when StripPrefix runs before ForwardAuth In those environments, an unauthenticated external attacker can influence the auth service's view of the protected path and gain access to backend routes that should be denied.