Skip to main content
CVE-2026-35051VulnerabilityPublished Updated

github.com/traefik/traefik/v3 · V3: Traefik's ForwardAuth trustForwardHeader=false allows spoofed X-Forwarded-Prefix to bypass authentication

Affects github.com/traefik/traefik/v3Source GCVE Database

0

Not known to be exploited · CVSS 10.0 Critical : upgrade to 3.7.0-rc.2 as a priority.

Data as of 27 Oct 2026, 00:07 UTC

CVSS 3.1 base score
10.0Critical
How severe the flaw is on the 0–10 CVSS scale.
Patch
Available – fixed in 3.7.0-rc.2, 3.6.14, 2.11.43
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade github.com/traefik/traefik/v3 to 3.7.0-rc.2; github.com/traefik/traefik/v3 to 3.6.14; github.com/traefik/traefik/v2 to 2.11.43.

Affected software

ProductAffectedFixed in
Gogithub.com/traefik/traefik/v3Affected
  • >=3.7.0-ea.1 <3.7.0-rc.2
Fixed in
  • 3.7.0-rc.2
Gogithub.com/traefik/traefik/v3Affected
  • >=3.0.0-beta1 <3.6.14
Fixed in
  • 3.6.14
Gogithub.com/traefik/traefik/v2Affected
  • <2.11.43
Fixed in
  • 2.11.43
Gogithub.com/traefik/traefikAffected
  • <=1.7.34
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

## Summary There is a high-severity authentication bypass vulnerability in Traefik's `ForwardAuth` middleware when `trustForwardHeader=false` is configured and Traefik is deployed behind a trusted upstream proxy. While `X-Forwarded-*` headers (such as `X-Forwarded-For`, `X-Forwarded-Host`, and `X-Forwarded-Proto`) from trusted context are correctly rebuilt, it does not strip or rebuild `X-Forwarded-Prefix`, leaving any attacker-supplied value intact in the subrequest forwarded to the authentication service. When the authentication service makes authorization decisions based on `X-Forwarded-Prefix`, an external attacker can spoof a trusted prefix value and gain unauthorized access to protected backend routes. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.43 - https://github.com/traefik/traefik/releases/tag/v3.6.14 - https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2 ## For more information If there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ### 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`](pkg/middlewares/auth/forward.go), `writeHeader` first copies all incoming request headers into the auth subrequest: ```go func writeHeader(req, forwardReq *http.Request, trustForwardHeader bool, allowedHeaders []string) { utils.CopyHeaders(forwardReq.Header, req.Header) ... forwardReq.Header = filterForwardRequestHeaders(forwardReq.Header, allowedHeaders) ``` 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`](pkg/middlewares/stripprefix/strip_prefix.go), Traefik appends the stripped prefix using `Header.Add`: ```go func (s *stripPrefix) serveRequest(rw http.ResponseWriter, req *http.Request, prefix string) { req.Header.Add(ForwardedPrefixHeader, prefix) ``` 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`: ```toml [entryPoints] [entryPoints.web] address = ":80" [entryPoints.web.forwardedHeaders] trustedIPs = ["172.31.79.0/24"] [providers] [providers.file] filename = "/etc/traefik/dynamic.toml" watch = false [log]

References

Community reviews

Loading reviews…