frp: Authentication bypass in frp HTTP vhost routing when routeByHTTPUser is used for access control

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

frp is a fast reverse proxy. From 0.43.0 to 0.68.0, frp contains an authentication bypass in the HTTP vhost routing path when routeByHTTPUser is used as part of access control. In proxy-style requests, the routing logic uses the username from Proxy-Authorization to select the routeByHTTPUser backend, while the access control check uses credentials from the regular Authorization header. As a result, an attacker who can reach the HTTP vhost entrypoint and knows or can guess the protected routeByHTTPUser value may access a backend protected by httpUser / httpPassword even with an incorrect Proxy-Authorization password. This issue affects deployments that explicitly use routeByHTTPUser. It does not affect ordinary HTTP proxies that do not use this feature. This vulnerability is fixed in 0.68.1.

Source published

21 Apr 2026 20:09:00 UTC

Source modified

21 Apr 2026 20:28:48 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 6.5 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

frp is a fast reverse proxy. From 0.43.0 to 0.68.0, frp contains an authentication bypass in the HTTP vhost routing path when routeByHTTPUser is used as part of access control. In proxy-style requests, the routing logic uses the username from Proxy-Authorization to select the routeByHTTPUser backend, while the access control check uses credentials from the regular Authorization header. As a result, an attacker who can reach the HTTP vhost entrypoint and knows or can guess the protected routeByHTTPUser value may access a backend protected by httpUser / httpPassword even with an incorrect Proxy-Authorization password. This issue affects deployments that explicitly use routeByHTTPUser. It does not affect ordinary HTTP proxies that do not use this feature. This vulnerability is fixed in 0.68.1.

Source published

Apr 21, 2026, 8:09:00 PM (timezone not stated)

Source modified

Apr 21, 2026, 8:28:48 PM (timezone not stated)

Observed here

28 Oct 2026 05:02:59 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 6.5 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

frp is a fast reverse proxy. From 0.43.0 to 0.68.0, frp contains an authentication bypass in the HTTP vhost routing path when routeByHTTPUser is used as part of access control. In proxy-style requests, the routing logic uses the username from Proxy-Authorization to select the routeByHTTPUser backend, while the access control check uses credentials from the regular Authorization header. As a result, an attacker who can reach the HTTP vhost entrypoint and knows or can guess the protected routeByHTTPUser value may access a backend protected by httpUser / httpPassword even with an incorrect Proxy-Authorization password. This issue affects deployments that explicitly use routeByHTTPUser. It does not affect ordinary HTTP proxies that do not use this feature. This vulnerability is fixed in 0.68.1.

Source published

21 Apr 2026 21:16:45 UTC

Source modified

26 Oct 2026 21:10:00 UTC

Observed here

27 Oct 2026 10:10:07 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 6.5 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

CVSS 3.1 · [email protected] · Primary · 9.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

### Summary frp contains an authentication bypass in the HTTP vhost routing path when `routeByHTTPUser` is used as part of access control. In proxy-style requests, the routing logic uses the username from `Proxy-Authorization` to select the `routeByHTTPUser` backend, while the access control check uses credentials from the regular `Authorization` header. As a result, an attacker who can reach the HTTP vhost entrypoint and knows or can guess the protected `routeByHTTPUser` value may access a backend protected by `httpUser` / `httpPassword` even with an incorrect `Proxy-Authorization` password. This issue affects deployments that explicitly use `routeByHTTPUser`. It does not affect ordinary HTTP proxies that do not use this feature. ### Details The issue is in `pkg/util/vhost/http.go`. In proxy-style requests using an absolute URI, the routing path extracts the username from `Proxy-Authorization` and stores it as the request `HTTPUser`, which is then used for `routeByHTTPUser` route selection. More specifically, `injectRequestInfoToCtx()` derives the routing user from `Proxy-Authorization`, while the original `ServeHTTP()` implementation used `req.BasicAuth()` for the authentication check. Because routing and authentication use different credential sources, a request can be routed to a protected backend based on the `Proxy-Authorization` username while the authentication check is not performed against the same credentials. This creates an authentication bypass when `routeByHTTPUser`, `httpUser`, and `httpPassword` are used together. This is not a universal anonymous bypass for all frp HTTP proxies; it is specific to deployments that use `routeByHTTPUser` and where the target user value is known or can be inferred. A minimal fix is to make the authentication check in proxy mode use the same credential source as route selection, i.e. to derive proxy-mode credentials from `Proxy-Authorization` consistently. From local Git history analysis, this logic appears to have been introduced by commit `4af85da0c2c6eb981142a8fdb44f885d26cb9d08`, with the earliest containing release tag appearing to be `v0.43.0`. ### PoC I reproduced the issue with the official `frp_0.68.0_linux_amd64.tar.gz` release binaries both locally and on an internet-reachable test server under my control. Minimal setup: - `frps` exposes an HTTP vhost entrypoint. - One HTTP proxy is configured with: - `customDomains = ["example.test"]` - `routeByHTTPUser = "alice"` - `httpUser = "alice"` - `httpPassword = "secret"` - The protected backend returns a constant marker string: `PRIVATE`. Minimal request flow: 1. Direct unauthenticated request: - `curl -i --proxy '' -H 'Host: example.test' http://<FRPS_HOST>:<VHOST_HTTP_PORT>/` - Result: `404 Not Found` 2. Direct request with correct backend credentials: - `curl -i --proxy '' -u alice:secret -H 'Host: example.test' http://<FRPS_HOST>:<VHOST_HTTP_PORT>/` - Result: `200 OK`, body contains `PRIVATE` 3. Proxy-style request with incorrect `Proxy-Authorization`: - `curl -i --noproxy '' -x http://<FRPS_HOST>:<VHOST_HTTP_PORT> --proxy-user alice:wrong http://example.test/` - Result: `200 OK`, body contains `PRIVATE` Observed minimal result summary: - `DIRECT_NOAUTH -> 404` - `DIRECT_BASICAUTH_GOOD -> 200 PRIVATE` - `PROXY_PROXYAUTH_WRONGPASS -> 200 PRIVATE` This was reproduced against the official binary, not only against a local source build. ### Impact This is an authentication bypass leading to unauthorized access to a protected backend. The practical impact depends on what service is behind the protected route. Examples include private application endpoints, internal administration panels, loopback-only local services, or development and operations interfaces. Important boundary: if the protected backend is an `frpc` admin API that is separately protected by its own `webServer.user` / `webServer.password`, this issue only bypasses the outer vhost restriction and does not automatically bypass the inner admin authentication. In that case, the request may still reach the backend but correctly receive `401 Unauthorized` from the inner layer. There is also a deployment-specific downstream impact path. If the bypassed backend is an `frpc` admin API without separate inner authentication, and if that `frpc` instance permits store-based proxy management, an attacker may be able to create additional plugin-based proxies through the admin API. In deployments where a `unix_domain_socket` proxy can be used to expose Docker's Unix socket, this may further expose the Docker API and potentially enable host-level command execution through Docker. This follow-on consequence depends on multiple additional deployment conditions and should be treated as a conditional downstream impact rather than the core vulnerability itself. Because exploitation requires a deployment to explicitly use `routeByHTTPUser`, and because the attacker must know or be able to guess the target `routeByHTTPUser` value, the issue is better classified as a configuration-dependent authentication bypass rather than a default-configuration issue.

Source published

14 Apr 2026 23:33:15 UTC

Source modified

25 Jun 2026 23:11:19 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

Publisher rating · MODERATE

frp has an authentication bypass in HTTP vhost routing when routeByHTTPUser is used for access control in github.com/fatedier/frp

Source published

25 Jun 2026 22:34:34 UTC

Source modified

25 Jun 2026 23:01:21 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.