GHSA-fvhj-4qfh-q2hm Traefik incorrectly processes fragment in the URL, leads to Authorization Bypass

• Go github.com/traefik/traefik/v2: < 2.10.6 → fixed in 2.10.6 • Go github.com/traefik/traefik/v3: < 3.0.0-beta5 → fixed in 3.0.0-beta5

Summary When a request is sent to Traefik with a URL fragment, Traefik automatically URL encodes and forwards the fragment to the backend server. This violates the RFC because in the origin-form the URL should only contain the absolute path and the query. When this is combined with another frontend proxy like Nginx, it can be used to bypass frontend proxy URI-based access control restrictions. Details For example, we have this Nginx configuration: ``` location /admin { deny all; return 403; } ``` This can be bypassed when the attacker is requesting to /#/../admin This won’t be vulnerable if the backend server follows the RFC and ignores any characters after the fragment. However, if Nginx is chained with another reverse proxy which automatically URL encode the character # (Traefik) the URL will become /%23/../admin And allow the attacker to completely bypass the Access Restriction from the Nginx Front-End proxy. Here is a diagram to summarize the attack: PoC This is the POC docker I've set up. It contains Nginx, Traefik proxies and a backend server running PHP. https://drive.google.com/file/d/1vLnA0g7N7ZKhLNmHmuJ4JJjV_J2akNMt/view?usp=sharing Impact This allows the attacker to completely bypass the Access Restriction from Front-End proxy.