CVE-2026-35051: 
NixOS vulnerability analysis and mitigation

CVE-2026-35051 is an authentication bypass vulnerability in Traefik's ForwardAuth middleware, triggered when trustForwardHeader=false is configured and Traefik is deployed behind a trusted upstream proxy. The flaw allows an unauthenticated remote attacker to spoof the X-Forwarded-Prefix header and bypass access controls protecting backend routes. It affects all Traefik versions up to and including v2.11.42, v3.6.13, and v3.7.0-rc.1. The vulnerability was published on April 30, 2026, and carries a CVSS v3.1 base score of 10.0 (Critical) and a CVSS v4.0 base score of 7.8 (High) (GitHub Advisory).

The root cause is classified as CWE-345 (Insufficient Verification of Data Authenticity). In pkg/middlewares/auth/forward.go, the writeHeader function copies all incoming request headers into the ForwardAuth subrequest and then selectively rebuilds only a subset of X-Forwarded-* headers (X-Forwarded-For, X-Forwarded-Method, X-Forwarded-Proto, X-Forwarded-Port, X-Forwarded-Host, X-Forwarded-Uri) when trustForwardHeader=false. However, X-Forwarded-Prefix is never stripped or rebuilt, so an attacker-supplied value persists in the subrequest sent to the authentication service. When StripPrefix middleware runs before ForwardAuth, it appends the legitimate stripped prefix via Header.Add, but the attacker's value appears first — allowing an auth service that evaluates the first X-Forwarded-Prefix value to be deceived into granting access to protected routes (GitHub Advisory).

Successful exploitation allows an unauthenticated external attacker to bypass ForwardAuth-enforced access controls and reach backend routes that should be denied. The primary impact is unauthorized access to confidential data and the ability to modify protected content on downstream systems, with high confidentiality and integrity impact on subsequent systems. Availability is not directly affected. The vulnerability is scoped to deployments that use Traefik behind a trusted upstream proxy with ForwardAuth and an auth service that makes routing or authorization decisions based on X-Forwarded-Prefix (GitHub Advisory).

A complete, reproducible proof-of-concept exploit is publicly available in the official GitHub Security Advisory, including Docker setup commands, configuration files, and curl requests demonstrating the bypass (GitHub Advisory). The vulnerability requires no authentication, no user interaction, and low attack complexity, making it highly automatable. As of the time of reporting, there is no evidence of active in-the-wild exploitation, and the EPSS score is approximately 0.01% (Feedly). The vulnerability is not currently listed in the CISA KEV catalog. No specific threat actor attribution has been reported.

1. Reconnaissance: Identify a Traefik deployment (v2.x < 2.11.43 or v3.0–3.6.x < 3.6.14) that is placed behind a trusted upstream reverse proxy (e.g., nginx) and uses the ForwardAuth middleware with trustForwardHeader=false and a StripPrefix middleware on the same route.
2. Understand the target route: Determine a protected route (e.g., /forbidden/) where StripPrefix runs before ForwardAuth, and the auth service grants access based on the first X-Forwarded-Prefix value (e.g., /admin).
3. Craft the malicious request: Send an HTTP request through the trusted upstream proxy (not directly to Traefik) with a spoofed X-Forwarded-Prefix header set to the privileged prefix value:

   curl -sS -i \
     -H 'Host: app.local' \
     -H 'X-Forwarded-Prefix: /admin' \
     http://<trusted-proxy>:<port>/forbidden/test

4. Header propagation: Because the trusted proxy's IP is in Traefik's trustedIPs list, Traefik does not strip the incoming X-Forwarded-Prefix. The StripPrefix middleware appends /forbidden via Header.Add, resulting in the auth subrequest containing both /admin (attacker-controlled, first) and /forbidden (Traefik-generated, second).
5. Auth bypass: The ForwardAuth service evaluates the first X-Forwarded-Prefix value (/admin), grants authorization, and returns HTTP 200.
6. Access protected backend: Traefik forwards the request to the protected backend service, which responds with the protected content, confirming the bypass (GitHub Advisory).

• Network: Unexpected HTTP requests arriving at Traefik via a trusted upstream proxy that include a pre-set X-Forwarded-Prefix header with values not matching the configured StripPrefix prefixes (e.g., /admin, /internal, /api).
• Logs: Traefik access logs showing requests to protected routes (e.g., /forbidden/) returning HTTP 200 when they should return 403; auth service logs showing first_prefix values that differ from the expected stripped prefix and match attacker-controlled strings.
• Auth Service Logs: Log entries where X-Forwarded-Prefix contains multiple values (e.g., /admin|/forbidden), indicating header stacking — the first value being attacker-supplied and the second being Traefik-generated.
• File System: No direct file system artifacts expected for this network-layer bypass; however, review backend application logs for unauthorized access to protected API endpoints or admin panels following suspicious ForwardAuth approvals (GitHub Advisory).

Traefik has released patched versions: v2.11.43 (for the 2.x series), v3.6.14 (for the 3.0–3.6 series), and v3.7.0-rc.2 (for the 3.7 pre-release series). Upgrading to one of these versions is the recommended remediation (v2.11.43 Release, v3.6.14 Release, v3.7.0-rc.2 Release). As a temporary workaround, operators can configure their auth service to not rely solely on the first X-Forwarded-Prefix value for authorization decisions, or ensure the upstream proxy strips the X-Forwarded-Prefix header before forwarding to Traefik. Additionally, if the upstream proxy is fully trusted and controlled, setting trustForwardHeader=true may be considered, though this should be done with caution (GitHub Advisory).

Traefik published an official community forum post announcing the security updates for versions 2.11.43, 3.6.14, and 3.7.0-rc.2, noting the multiple CVEs addressed in the release (Traefik Community). The vulnerability was credited to researcher "Zwique" in the official advisory. Tenable added detection coverage via Nessus plugin 311474 shortly after disclosure. A technical write-up was published at infinitsec.net analyzing the header spoofing mechanism (infinitsec.net). The release also noted that ForwardAuth.TrustForwardHeader is being deprecated in v3.6.14 and v3.7.0-rc.2 as a longer-term architectural response.