FlawAtlas
Search the atlas
CVE-2026-40912 High

Traefik has an StripPrefixRegex Middleware Authorization Bypass via Path/RawPath Desync in github.com/traefik/traefik

Traefik has an StripPrefixRegex Middleware Authorization Bypass via Path/RawPath Desync in github.com/traefik/traefik

Exploit probability 0.8%
Published June 25, 2026
Required by Not available
Last source change June 25, 2026

02 / AFFECTED SOFTWARE

Affected packages

Go github.com/traefik/traefik
Go github.com/traefik/traefik/v2
Go github.com/traefik/traefik/v3
Unknown Unknown

290 explicit affected versions

Go github.com/traefik/traefik
Go github.com/traefik/traefik/v2
Go github.com/traefik/traefik/v3

03 / CONNECTIONS

Connected vulnerabilities

related OPENSUSE-SU-2026:21483-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities GHSA-6jwx-7vp4-9847

## Summary There is a high severity authentication bypass vulnerability in Traefik's `StripPrefixRegex` middleware when used in combination with `ForwardAuth`, `BasicAuth`, or `DigestAuth`. The middleware matches the regex against the decoded URL path but uses the resulting byte length to slice the percent-encoded raw path. When a dot (or multiple dots) appears in the prefix portion of the URL, the raw path after stripping becomes a dot-segment (e.g. `/./admin/secret`). `ForwardAuth` receives this dot-segment path in `X-Forwarded-Uri`, which does not match the protected path patterns and therefore allows the request through. The backend then normalizes the dot-segment to the real path per RFC 3986 and serves the protected content An unauthenticated attacker can exploit this against any backend that performs dot-segment normalization. ## 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 StripPrefixRegex uses the byte length of a decoded Path match to slice the encoded RawPath. When percent-encoded characters are in the prefix region, this produces a wrong RawPath. ForwardAuth then receives this wrong path in X-Forwarded-Uri, sees a path that doesn't match its protection rules, and approves the request. The backend serves protected content. ### Details `pkg/middlewares/stripprefixregex/strip_prefix_regex.go`, line 62: ```go req.URL.RawPath = ensureLeadingSlash(req.URL.RawPath[len(prefix):]) ``` prefix comes from matching the regex against the decoded req.URL.Path (line 51). len(prefix) is then used to index into the encoded req.URL.RawPath. These lengths don't match when percent-encoding is present. Example with regex ^/api: - GET /api%20/admin/secret - Decoded Path: /api /admin/secret -> prefix = /api (4 bytes) - Encoded RawPath: /api%20/admin/secret -> same region is 6 bytes - RawPath[4:] = %20/admin/secret -> after ensureLeadingSlash -> /%20/admin/secret - ForwardAuth sees X-Forwarded-Uri: /%20/admin/secret -> not /admin/* -> allows it - Backend serves the protected admin content PoC Requires Docker and Docker Compose. I have a setup that runs Traefik v3.6.11 with StripPrefixRegex + ForwardAuth + a backend. It sends a normal request (blocked, 403) and an encoded request (bypasses auth, 200, returns protected data). Can share the files here if useful. Impact Auth bypass. Any path protected by ForwardAuth, BasicAuth, or DigestAuth can be accessed without credentials when StripPrefixRegex is in the same middleware chain. The attacker only needs to add a percent-encoded character to the prefix portion of the URL. --- ### Updated PoC (reporter follow-up) After further testing, the confirmed working exploit uses `%2e` (percent-encoded dot) rather than `%20`. Dot-segment normalization (`/./` -> `/`) is RFC 3986 standard behavior handled automatically by Express.js, Go's `http.ServeMux`, Spring Boot, and others — no custom configuration needed. Chain: ``` GET /api%2e/admin/secret -> StripPrefixRegex strips /api -> RawPath becomes /./admin/secret -> ForwardAuth sees /./admin/secret -> does not match /admin/ -> allows -> Express normalizes /./admin/secret -> /admin/secret -> serves protected content ``` Results (Traefik v3.6, unmodified Express.js express.static): ``` GET /api/admin/secret -> 403 (blocked) GET /api%2e/admin/secret -> 200 (bypass — served protected content) GET /api%20/admin/secret -> 404 (space not normalized by backend) ``` Auth server logs: ``` X-Forwarded-Uri: '/admin/secret' -> DENIED X-Forwarded-Uri: '/./admin/secret' -> ALLOWED ``` Reproduction: ```bash docker compose up -d --build --wait curl http://localhost:8080/api/admin/secret # -> 403 curl --path-as-is "http://localhost:8080/api%2e/admin/secret" # -> 200 ``` </details> ---

View original source
Open Source Vulnerabilities GO-2026-5180

Traefik has an StripPrefixRegex Middleware Authorization Bypass via Path/RawPath Desync in github.com/traefik/traefik

View original source
Open Source Vulnerabilities CVE-2026-40912

Traefik is an HTTP reverse proxy and load balancer. Prior to versions 2.11.43, 3.6.14, and 3.7.0-rc.2, there is a high severity authentication bypass vulnerability in Traefik's StripPrefixRegex middleware when used in combination with ForwardAuth, BasicAuth, or DigestAuth. The middleware matches the regex against the decoded URL path but uses the resulting byte length to slice the percent-encoded raw path. When a dot (or multiple dots) appears in the prefix portion of the URL, the raw path after stripping becomes a dot-segment (e.g. /./admin/secret). ForwardAuth receives this dot-segment path in X-Forwarded-Uri, which does not match the protected path patterns and therefore allows the request through. The backend then normalizes the dot-segment to the real path per RFC 3986 and serves the protected content An unauthenticated attacker can exploit this against any backend that performs dot-segment normalization. This issue has been patched in versions 2.11.43, 3.6.14, and 3.7.0-rc.2.

View original source

05 / REFERENCES

Further evidence