GHSA-vrch-868g-9jx5
Traefik allows path traversal using url encoding
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/traefik/traefik/v3🐹github.com/traefik/traefik/v2🐹github.com/traefik/traefikReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
There is a potential vulnerability in Traefik managing the requests using a PathPrefix, Path or PathRegex matcher.
When Traefik is configured to route the requests to a backend using a matcher based on the path, if the URL contains a URL encoded string in its path, it’s possible to target a backend, exposed using another router, by-passing the middlewares chain.
Example
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
name: my-service
spec:
routes:
- match: PathPrefix(‘/service’)
kind: Rule
services:
- name: service-a
port: 8080
middlewares:
- name: my-middleware-a
- match: PathPrefix(‘/service/sub-path’)
kind: Rule
services:
- name: service-a
port: 8080
In such a case, the request http://mydomain.example.com/service/sub-path/%2e%2e/other-path will reach the backend my-service-a without operating the middleware my-middleware-a unless the computed path is http://mydomain.example.com/service/other-path and should be computes by the first router (operating my-middleware-a).
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.25
- https://github.com/traefik/traefik/releases/tag/v3.4.1
For more information
If you have any questions or comments about this advisory, please open an issue.
<details> <summary>Original Description</summary> ### SummaryPath traversal with "/../" using URL encodings ("/%2e%2e") allows for circumventing routing rules.
Details
When having defined a route, you can path traverse using the URL encoded variant of /../ and reach endpoints that are not made publicly available. This issue has been found and fixed earlier with regular /../ and has been fixed in this CVE. This URL encoding trick works around that https://nvd.nist.gov/vuln/detail/CVE-2025-32431
Simply implementing a check on the URL encoding won't be sufficient as path traversal can take numerous formats. See examples here: https://book.hacktricks.wiki/en/pentesting-web/file-inclusion/index.html
PoC
Setup a service with two endpoints: "/public" and "/private", which returns a 200 OK for both Setup a Traefik proxy with a single route which points to the service using path /public
Regular requests to traefik /public will return 200 OK and to /private should return 404 (response by Traefik) When making a request to /public/%2e%2e/private you should receive a 200 OK.
Impact
Impacts all traefik implementations with path prefix routes that expose only part of the downstream api
Suggestion
Provide configuration property which disables all path traversals. Steps:
- Decode URL
- Evaluate and construct relative path (do traversal before route evaluation)
- Compare relative/evaluated path to configured routes (PathPrefix/pathRegexp)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/traefik/traefik/v3 | all versions | 3.4.1 |
| 🐹Go | github.com/traefik/traefik/v2 | all versions | 2.11.25 |
| 🐹Go | github.com/traefik/traefik | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/traefik/traefik/v3. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/traefik/traefik/v3 to 3.4.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vrch-868g-9jx5 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vrch-868g-9jx5 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vrch-868g-9jx5. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vrch-868g-9jx5 in your dependencies?
O3 detects GHSA-vrch-868g-9jx5 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.