Traefik shipped three authentication bypasses in 24 hours. The same root cause is in every reverse proxy.

# Traefik shipped three authentication bypasses in 24 hours. The same root cause is in everyone's reverse proxy.

On April 25 2026, the Traefik project published three high-severity authentication-bypass advisories on the same day:

• GHSA-6jwx-7vp4-9847: StripPrefixRegex middleware allows authorization bypass via Path / RawPath desync.
• GHSA-5m6w-wvh7-57vm: Pre-authentication decision bypass via forwarded alias spoofing.
• GHSA-6384-m2mw-rf54: ForwardAuth with trustForwardHeader=false still allows spoofed X-Forwarded-Prefix to bypass authentication.

All three are pre-authentication. All three let an unauthenticated attacker reach a protected backend. All three are variants of the same underlying bug class: the reverse proxy normalized the URL or trusted a header before evaluating the access policy, but the backend used a different normalization or trusted a different header for routing.

This is the canonical reverse-proxy authentication failure pattern. It is not unique to Traefik. It has hit nginx, Envoy, HAProxy, IIS ARR, and every CDN that does authenticated edge routing. Traefik just happens to have shipped three variants in one bug bash. If you operate Traefik in front of admin endpoints, patch immediately. Then read the rest of this post because the same bug class probably lives elsewhere in your stack.

#Bug 1: Path / RawPath desync in StripPrefixRegex

The vulnerable middleware lets you strip a regex-matched prefix from the request path before forwarding to the backend. The intended use case: route /api/v1/users/me from the public surface to /users/me internally, while the access-control middleware ahead of it inspects the public path.

The bug: Go's net/url package keeps both Path (decoded) and RawPath (original). The access-control evaluation read Path. The strip-prefix evaluation read RawPath. An attacker submits a URL where these differ, for example, /admin/%2e%2e/public, and the two evaluations disagree.

In the wrong direction, Path decodes to /public (passes the public-route policy), but RawPath after strip is /admin/../public which the backend resolves to /admin/. Authenticated admin endpoints become reachable from the public route.

The fix in Traefik is to canonicalize both representations to the same value before any policy decision. The lesson for everyone else is that any time you have two stages of URL handling that read the URL differently, you have a desync risk.

#Bug 2: Forwarded-alias spoofing for pre-auth decisions

X-Forwarded-Host, X-Forwarded-Prefix, X-Forwarded-Proto, and X-Forwarded-For are the standard headers for proxies to communicate request metadata to backends. Traefik routes can be configured to make access-control decisions based on these headers, for example, "this rule applies only when X-Forwarded-Host is admin.example.com."

The bug: when the client connects directly to Traefik, the client controls these headers. There is no upstream proxy stripping them. An attacker can set X-Forwarded-Host: admin.example.com and Traefik trusts the value. Combined with a route policy that gates admin access on the host header, the attacker bypasses the policy.

The fix is to either strip these headers on ingress, or to evaluate access control against the actual TCP-level connection metadata (the Host: header, the SNI, the source IP), not the forwarded-by-client metadata.

This is the same bug as the original Host-header vulnerabilities from the early HTTP/1.1 era. The lesson: headers controlled by the client are not authentication. Even if the header looks like infrastructure metadata, if the client can set it, an attacker can set it.

#Bug 3: ForwardAuth + spoofed X-Forwarded-Prefix

ForwardAuth is a Traefik feature that delegates authentication to an external service. The proxy issues a sub-request to the auth service, the auth service returns 200 (allow) or 401/403 (deny), and Traefik forwards the original request only if allowed. trustForwardHeader=false is supposed to mean "do not trust client-supplied X-Forwarded-* headers when constructing the auth sub-request." If you set this to false, you expect the auth service to receive only the headers Traefik itself sets.

The bug: X-Forwarded-Prefix was not in the strip list. Even with trustForwardHeader=false, the client's X-Forwarded-Prefix was forwarded to the auth service. The auth service made its decision based on that header. An attacker submits the auth-bypassing prefix, the auth service authorizes the sub-request, Traefik forwards the original.

The fix is to strip X-Forwarded-Prefix along with the others when trustForwardHeader=false. The lesson: opt-out lists for header trust are dangerous. If your opt-out is "trust this set of headers," and the set has gaps, attackers find the gaps. Opt-in is safer: explicitly list which headers are passed through, default-deny everything else.

#The pattern across all three

Each bug is a different mechanism, but the underlying failure is the same:

> A boundary between two layers had a mismatch. The mismatch was in URL normalization (bug 1), in the trust model for client-controlled headers (bug 2), or in the opt-out list of which headers to strip (bug 3). At the seam, an attacker found a way to make the inner layer disagree with the outer layer about what the request was. The outer layer's authentication decision did not apply to what the inner layer actually processed.

This is the canonical reverse-proxy authentication failure pattern. It has shown up in:

• nginx, repeated path-normalization bugs over the years.
• Envoy, header-injection bypasses around x-envoy-original-path.
• HAProxy, request-smuggling variants tied to Transfer-Encoding / Content-Length mismatches.
• AWS API Gateway, host-header-controlled routing decisions in early versions of the lambda-proxy integration.
• Cloudflare Workers, early variants of the URL-canonicalization rules between Workers and origin.
• IIS / ARR, the canonical-double-decode bug from the early 2000s.

If you have a reverse proxy or CDN in front of an authenticated backend, you have this risk surface. Traefik's three advisories are the same bug Hannah Arendt would call the banality of evil, there is nothing exotic about any of them, the failure mode is well-known, and the fixes are all small. They keep happening because the surface area is large and the seams are subtle.

#What to do this week if you run Traefik

1. Patch immediately. Traefik 3.x has releases with the three fixes. If you are on an older 2.x branch, apply the equivalent backports or upgrade.

1. Audit your StripPrefixRegex rules. If you have any rule that strips a prefix where the post-strip path could legally contain .. or URL-encoded path traversal, that rule is suspicious. Fix or remove.

1. Audit your X-Forwarded-* trust. Open your Traefik config. Find every reference to X-Forwarded-Host, X-Forwarded-Prefix, X-Forwarded-Proto. Confirm that for each, you are stripping client-supplied values on ingress. The default Traefik behavior strips these only in some configurations; an audit is the only way to know.

1. Audit ForwardAuth configurations. If you have trustForwardHeader=false set, inspect the request your auth service actually sees. Use a debug logger to dump every header. Confirm X-Forwarded-Prefix is not present in client-controllable form.

1. Add a regression test. For each ForwardAuth rule you have, write a test that sends a request with a malicious X-Forwarded-Prefix value and asserts the auth service returns 401. If you do not have this test, you cannot ship a fix and verify it.

#What to do this week if you don't run Traefik

The same bug class exists in your reverse-proxy or CDN config. It does not say "Traefik" on the outside, but the underlying pattern is universal.

Look for these patterns in your stack:

• Anywhere your access-control policy reads a header that the backend also reads. If both layers can read X-Original-URL, X-Rewrite-URL, X-Forwarded-Path, or Host, those headers must come from a trusted source. Strip on ingress; don't trust client values.

• Anywhere you do URL rewriting before authorization. If you rewrite /admin/... to /internal/... at the edge but the access policy is on the original path, an attacker who can influence the rewrite (via path traversal, URL encoding, or alternate path representations) bypasses the policy.

• Anywhere your auth service trusts the proxy's representation of the request. If your auth service receives the path as a header (X-Original-Path) and trusts it, that header must be set by the proxy and the proxy must strip the client's version. If both can set it, the client wins.

#Where Valtik fits

Reverse-proxy authentication-bypass audits are part of every infrastructure engagement we run. We test for:

• URL-normalization differences between edge and origin.
• Header-trust gaps between the ingress proxy and the auth service.
• Pre-auth headers whose values control downstream authorization decisions.
• Forwarded-* header cluster-wide audit (Traefik, nginx, Envoy, HAProxy, ALB, Cloudflare, Fastly, Akamai).

If you operate Traefik or any reverse proxy in front of admin endpoints and you have not had the configuration audited in the last 12 months, it is time. Email tre@valtikstudios.com or use the /free-check form.

---

References:

1. GHSA-6jwx-7vp4-9847, Traefik StripPrefixRegex Middleware Authorization Bypass via Path/RawPath Desync. 2026-04-25.
2. GHSA-5m6w-wvh7-57vm, Traefik: Pre-authentication decision bypass due to forwarded alias spoofing. 2026-04-25.
3. GHSA-6384-m2mw-rf54, Traefik's ForwardAuth trustForwardHeader=false allows spoofed X-Forwarded-Prefix. 2026-04-25.
4. PortSwigger Web Security Academy, HTTP Host header attacks.
5. James Kettle, "Practical HTTP Header Smuggling," Black Hat 2021.