Listen to this Post
The vulnerability (no assigned CVE but described as high severity) lies in Traefik’s ForwardAuth middleware when `trustForwardHeader=false` is set and Traefik runs behind a trusted upstream proxy. The `writeHeader` function in `pkg/middlewares/auth/forward.go` copies all incoming request headers into the auth subrequest. Then it selectively rebuilds a subset of `X-Forwarded-` headers (e.g., X-Forwarded-For, X-Forwarded-Host) but does not rebuild or remove X-Forwarded-Prefix. An attacker can send a spoofed `X-Forwarded-Prefix: /admin` header. When `StripPrefix` middleware runs before ForwardAuth, Traefik appends the stripped prefix (e.g., /forbidden) using Header.Add. The auth service receives both headers in order: attacker’s `/admin` then Traefik’s /forbidden. Many auth services take the first value, thus thinking the request originated from `/admin` instead of /forbidden. Since `trustForwardHeader=false` is supposed to discard untrusted forwarded headers, this breaks the trust boundary. Direct requests to Traefik (without a proxy) correctly ignore the spoofed header and return 403. But when the request passes through a trusted upstream proxy that sets `X-Forwarded-For` etc., Traefik accepts the proxy as trusted and forwards the attacker’s `X-Forwarded-Prefix` untouched to the auth service. The PoC uses Traefik v3.6.12, Nginx as trusted proxy, and a Python auth server that authorizes only /admin. Spoofing `/admin` grants access to /forbidden/test, proving bypass.
Platform: Traefik
Version: v3.6.12
Vulnerability: Auth Bypass
Severity: High
date: 2026-04-24
Prediction: Unknown within 30d
What Undercode Say:
Create traefik.toml with trusted IPs cat > traefik.toml <<EOF [entryPoints.web] address = ":80" [entryPoints.web.forwardedHeaders] trustedIPs = ["172.31.79.0/24"] [providers.file] filename = "/etc/traefik/dynamic.toml" EOF dynamic.toml with strip-prefix then forwardAuth cat > dynamic.toml <<EOF [http.routers.app] rule = "Host(\`app.local\`) && PathPrefix(\`/forbidden\`)" middlewares = ["strip-forbidden", "authz"] service = "backend" [http.middlewares.strip-forbidden.stripPrefix] prefixes = ["/forbidden"] [http.middlewares.authz.forwardAuth] address = "http://auth:8000/check" trustForwardHeader = false EOF Spoofed request through trusted proxy (bypass) curl -H 'Host: app.local' -H 'X-Forwarded-Prefix: /admin' http://127.0.0.1:18080/forbidden/test
Exploit:
Attacker places a reverse proxy (e.g., Nginx) on a trusted IP range defined in Traefik’s trustedIPs. The proxy forwards any client request. Attacker sends `X-Forwarded-Prefix: /admin` to the proxy. Traefik sees the proxy as trusted, copies the malicious header into the auth subrequest without stripping it. StripPrefix later appends the real prefix (/forbidden), but the auth service uses the first value (/admin) and grants access to `/forbidden` routes.
Protection from this CVE:
Upgrade Traefik to a patched version (v3.6.13+ or v3.7+ where `X-Forwarded-Prefix` is rebuilt or removed when trustForwardHeader=false). As a workaround, configure `authRequestHeaders` to explicitly exclude X-Forwarded-Prefix, or override it in the auth service to always ignore the first value and use the last (Traefik-generated) prefix. Alternatively, avoid using `StripPrefix` together with `ForwardAuth` until patched.
Impact:
Unauthenticated remote attacker bypasses path-based authorization, accessing protected backend routes that should be forbidden. Affects any deployment where Traefik sits behind a trusted proxy, uses `ForwardAuth` with trustForwardHeader=false, and the auth server reads `X-Forwarded-Prefix` for decisions. Complete authentication bypass leading to data exposure or unauthorized actions.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
