Vulnerability-Lookup

CVE-2026-40910 (GCVE-0-2026-40910)

Vulnerability from cvelistv5 – Published: 2026-04-21 20:09 – Updated: 2026-04-21 20:28

Title

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

Summary

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.

Severity ?

6.5 (Medium)


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

CWE

CWE-287 - Improper Authentication

Assigner

GitHub_M

References

URL

Tags

https://github.com/fatedier/frp/security/advisori…

x_refsource_CONFIRM

Impacted products

	Vendor	Product	Version
	fatedier	frp	Affected: < 0.68.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-40910",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-04-21T20:28:44.365794Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-04-21T20:28:48.579Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "frp",
          "vendor": "fatedier",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.68.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-04-21T20:09:00.893Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9"
        }
      ],
      "source": {
        "advisory": "GHSA-pq96-pwvg-vrr9",
        "discovery": "UNKNOWN"
      },
      "title": "frp: Authentication bypass in frp HTTP vhost routing when routeByHTTPUser is used for access control"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-40910",
    "datePublished": "2026-04-21T20:09:00.893Z",
    "dateReserved": "2026-04-15T16:37:22.767Z",
    "dateUpdated": "2026-04-21T20:28:48.579Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-40910",
      "date": "2026-04-22",
      "epss": "0.00041",
      "percentile": "0.12677"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-40910\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-04-21T21:16:45.157\",\"lastModified\":\"2026-04-22T21:24:26.997\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N\",\"baseScore\":6.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"LOW\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":2.2,\"impactScore\":4.2}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-287\"}]}],\"references\":[{\"url\":\"https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9\",\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-40910\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-04-21T20:28:44.365794Z\"}}}], \"references\": [{\"url\": \"https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-04-21T20:28:37.740Z\"}}], \"cna\": {\"title\": \"frp: Authentication bypass in frp HTTP vhost routing when routeByHTTPUser is used for access control\", \"source\": {\"advisory\": \"GHSA-pq96-pwvg-vrr9\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 6.5, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N\", \"integrityImpact\": \"LOW\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"fatedier\", \"product\": \"frp\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 0.68.1\"}]}], \"references\": [{\"url\": \"https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9\", \"name\": \"https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9\", \"tags\": [\"x_refsource_CONFIRM\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-287\", \"description\": \"CWE-287: Improper Authentication\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-04-21T20:09:00.893Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-40910\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-04-21T20:28:48.579Z\", \"dateReserved\": \"2026-04-15T16:37:22.767Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-04-21T20:09:00.893Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

GHSA-PQ96-PWVG-VRR9

Vulnerability from github – Published: 2026-04-14 23:33 – Updated: 2026-04-14 23:33

Summary

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

Details

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

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
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.

Severity ?

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.68.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fatedier/frp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.43.0"
            },
            {
              "fixed": "0.68.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:33:15Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nfrp 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.\n\nThis issue affects deployments that explicitly use `routeByHTTPUser`. It does not affect ordinary HTTP proxies that do not use this feature.\n\n### Details\nThe issue is in `pkg/util/vhost/http.go`.\n\nIn 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.\n\nMore specifically, `injectRequestInfoToCtx()` derives the routing user from `Proxy-Authorization`, while the original `ServeHTTP()` implementation used `req.BasicAuth()` for the authentication check.\n\nBecause 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.\n\nThis 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.\n\nA 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.\n\nFrom 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`.\n\n### PoC\nI 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.\n\nMinimal setup:\n- `frps` exposes an HTTP vhost entrypoint.\n- One HTTP proxy is configured with:\n  - `customDomains = [\"example.test\"]`\n  - `routeByHTTPUser = \"alice\"`\n  - `httpUser = \"alice\"`\n  - `httpPassword = \"secret\"`\n- The protected backend returns a constant marker string: `PRIVATE`.\n\nMinimal request flow:\n1. Direct unauthenticated request:\n   - `curl -i --proxy \u0027\u0027 -H \u0027Host: example.test\u0027 http://\u003cFRPS_HOST\u003e:\u003cVHOST_HTTP_PORT\u003e/`\n   - Result: `404 Not Found`\n\n2. Direct request with correct backend credentials:\n   - `curl -i --proxy \u0027\u0027 -u alice:secret -H \u0027Host: example.test\u0027 http://\u003cFRPS_HOST\u003e:\u003cVHOST_HTTP_PORT\u003e/`\n   - Result: `200 OK`, body contains `PRIVATE`\n\n3. Proxy-style request with incorrect `Proxy-Authorization`:\n   - `curl -i --noproxy \u0027\u0027 -x http://\u003cFRPS_HOST\u003e:\u003cVHOST_HTTP_PORT\u003e --proxy-user alice:wrong http://example.test/`\n   - Result: `200 OK`, body contains `PRIVATE`\n\nObserved minimal result summary:\n- `DIRECT_NOAUTH -\u003e 404`\n- `DIRECT_BASICAUTH_GOOD -\u003e 200 PRIVATE`\n- `PROXY_PROXYAUTH_WRONGPASS -\u003e 200 PRIVATE`\n\nThis was reproduced against the official binary, not only against a local source build.\n\n### Impact\nThis is an authentication bypass leading to unauthorized access to a protected backend.\n\nThe 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.\n\nImportant 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.\n\nThere 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\u0027s 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.\n\nBecause 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.",
  "id": "GHSA-pq96-pwvg-vrr9",
  "modified": "2026-04-14T23:33:15Z",
  "published": "2026-04-14T23:33:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fatedier/frp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "frp has an authentication bypass in HTTP vhost routing when routeByHTTPUser is used for access control"
}

FKIE_CVE-2026-40910

Vulnerability from fkie_nvd - Published: 2026-04-21 21:16 - Updated: 2026-04-22 21:24

Severity ?

6.5 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9
	134c704f-9b21-4f2e-91b3-4a467353bcc0	https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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."
    }
  ],
  "id": "CVE-2026-40910",
  "lastModified": "2026-04-22T21:24:26.997",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 6.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 4.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-04-21T21:16:45.157",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/fatedier/frp/security/advisories/GHSA-pq96-pwvg-vrr9"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-287"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

CVE-2026-40910 (GCVE-0-2026-40910)

GHSA-PQ96-PWVG-VRR9

Summary

Details

PoC

Impact

FKIE_CVE-2026-40910

Tags

Sightings

Nomenclature