Listen to this Post
How the CVE Works:
The vulnerability exists in frp’s HTTP vhost routing when `routeByHTTPUser` is enabled. In proxy-style requests using absolute URIs, the routing logic extracts the username from the `Proxy-Authorization` header and stores it as the request’s `HTTPUser` for route selection via injectRequestInfoToCtx(). However, the authentication check in `ServeHTTP()` uses `req.BasicAuth()` which reads the standard `Authorization` header. This mismatch allows an attacker to send a request with a correct `Proxy-Authorization` username (to match routeByHTTPUser) but an arbitrary or wrong password. The request routes to the protected backend because the routing user matches, while the authentication check fails to validate the same credentials because it looks at a different header. As a result, the backend protected by httpUser/httpPassword is accessible without the correct password. The issue was introduced in commit `4af85da0c2c6eb981142a8fdb44f885d26cb9d08` (v0.43.0) and affects versions up to and including the tested v0.68.0. Exploitation requires knowledge of the `routeByHTTPUser` value and network access to the vhost entrypoint.
dailycve form:
Platform: frp
Version: v0.43.0–v0.68.0
Vulnerability: Authentication Bypass
Severity: Medium
Date: 2025-??-??
Prediction: Patch 2025-02-15
What Undercode Say:
Identify vulnerable frp version frps --version | grep -E "0.[4-6][3-9]." && echo "Vulnerable" Test for bypass (requires known routeByHTTPUser value) curl -x http://<FRPS_HOST>:<VHOST_PORT> --proxy-user alice:wrong http://example.test/ -v Check routing logic in source grep -n "injectRequestInfoToCtx" pkg/util/vhost/http.go grep -n "BasicAuth" pkg/util/vhost/http.go
Exploit:
Attacker guesses routeByHTTPUser = "admin" curl --noproxy '' -x http://target:8080 --proxy-user admin:anypassword http://protected.internal/ Returns 200 with private data despite wrong password
Protection from this CVE:
- Disable `routeByHTTPUser` unless strictly required.
- Upgrade to patched version (fix pending; watch GitHub releases).
- Use mutual TLS or IP whitelisting as additional layer.
- Apply workaround: move authentication to backend service itself.
Impact:
Unauthorized access to internal HTTP services behind frp proxy. May expose admin panels, local APIs, or Docker sockets if chained with weak internal auth. Full host compromise possible in specific deployments where bypassed backend permits proxy creation and Unix socket exposure.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
