Every CVE Search/ Get API key

CVE-2026-40910

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

6.5 MediumFix available

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
High
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
High
Integrity
Low
Availability
None

Exploit likelihood

0.27%Up 0.2 points since Apr 22, 2026
90%50%10%1%

What each source reports

CVE List Score used 6.5

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

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.

Record
CVE-2026-40910
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Weakness
CWE-287
Updated
2026-11-02
EUVDEUVD-2026-24477 6.5

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.

Record
EUVD-2026-24477
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-pq96-pwvg-vrr9 6.5

frp has an authentication bypass in HTTP vhost routing when routeByHTTPUser is used for access control

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…

Record
GHSA-pq96-pwvg-vrr9
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Weakness
CWE-287
Updated
2026-11-02
NVD 6.5

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.

Record
CVE-2026-40910
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Weakness
CWE-287
Updated
2026-11-02
OSV 6.5

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

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.

Record
CVE-2026-40910
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Weakness
CWE-287
Updated
2026-11-02
OSVGHSA-pq96-pwvg-vrr9 6.5

frp has an authentication bypass in HTTP vhost routing when routeByHTTPUser is used for access control

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…

Record
GHSA-pq96-pwvg-vrr9
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Weakness
CWE-287
Updated
2026-11-02
OSVGO-2026-5549 No score

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

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

Record
GO-2026-5549
Updated
2026-11-02
OSVopenSUSE-SU-2026:21483-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
  • GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
  • GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
  • GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
  • GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
  • GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
  • GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
  • GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
  • GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
  • GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
  • GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
  • GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
  • GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
  • GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
  • GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
  • GO-2026-5933 GHSA-3g4q-2f67-2gvh
  • GO-2026-5934 GHSA-59qp-cfj3-rp64
  • GO-2026-5935 GHSA-7856-g3gv-9wq8
  • GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
  • GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
  • GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
  • GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
  • GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
  • GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
  • GO-2026-5942 CVE-2026-46600
  • GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
  • GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
  • GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
  • GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
  • GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
  • GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
  • GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
  • GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
  • GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
  • GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
  • GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
  • GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
  • GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
  • GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
  • GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
  • GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
  • GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
  • GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
  • GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
  • GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
  • GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
  • GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
  • GO-2026-5969 GHSA-g936-7jqj-mwv8
  • GO-2026-5970 CVE-2026-56852
  • GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
  • GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
  • GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
  • GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
  • GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
  • GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
  • GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
  • GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
  • GO-2026-5981 GHSA-mqxv-9rm6-w8qc
  • GO-2026-5982 GHSA-pqg7-v6wh-3pfp
  • GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
  • GO-2026-5985 GHSA-7rx3-5wx3-5v76
  • GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
  • GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
  • GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
  • GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
  • GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
  • GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
  • GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
  • GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
  • GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
  • GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
  • GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
  • GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
  • GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
  • GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
  • GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
  • GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…
Record
openSUSE-SU-2026:21483-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/fatedier/frp
Go
 0.43.0 to 0.68.0
0.68.1
github.com/fatedier/frp
Go
 0.43.0 up to 0.68.1
0.68.1
govulncheck-vulndb
openSUSE:Leap 16.0
From an advisory covering 1734 CVEs
 before 0.0.20260723T184607-160000.1.1
0.0.20260723T184607-160000.1.1

History

History
RecordedChangedSources
affected, facts
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-40910 is a medium vulnerability (CVSS 6.5) in Fatedier Frp, published April 14, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.27%, the 19th percentile. Fixed in github.com/fatedier/frp 0.68.1.

References

Show 194 moreShow less
This page doesn't list everything

Left out here: 1,539 references and the rest of 3 source descriptions. The JSON record has them.

Pages All vulnerabilities Browse Docs Sources Guide Get API key
MoveEnter Open