GHSA-26GQ-P25F-99CP

Vulnerability from github – Published: 2026-07-24 21:48 – Updated: 2026-07-24 21:48
VLAI
Summary
frp: Unauthenticated Remote Denial of Service in the frp SSH Tunnel Gateway via Integer Overflow
Details

Summary

An integer-overflow vulnerability in the frp server's optional SSH Tunnel Gateway lets any unauthenticated remote attacker crash the entire frps process with a single five-byte message. When the gateway parses an SSH exec channel request in pkg/ssh/server.go, it adds a small constant to a four-byte length value taken directly from the request. Because that length is fully attacker-controlled, a value of 0xFFFFFFFF makes the addition wrap around to a tiny number, defeating the only bounds check and forcing an out-of-range slice. Go raises a panic that nothing recovers, so the whole server exits. In the default gateway mode SSH clients are not authenticated and the request is handled before any frp token is checked, so the crash is reachable pre-authentication. It carries no state and is trivially repeatable, turning one crash into a sustained outage that drops every tunnel for every user.

Details

The exec request payload is a four-byte big-endian length followed by that many command bytes, and the length field is fully attacker-controlled. The gateway computes the end of the command as 4 + length. The constant 4 takes the uint32 type of the length field, so 4 + 0xFFFFFFFF wraps modulo 2^32 to 3. The only guard compares the real payload size against this wrapped value, so a five-byte payload passes the test 5 < 3, and the slice runs from index 4 to index 3:

// pkg/ssh/server.go:315-319
end := 4 + binary.BigEndian.Uint32(req.Payload[:4])  // 4 + 0xFFFFFFFF wraps to 3
if len(req.Payload) < int(end) {                     // 5 < 3 is false, so it passes
    continue
}
extraPayload := string(req.Payload[4:end])           // payload[4:3] -> panic

The handler runs in a bare goroutine and no function in the call chain installs a recover, so the panic unwinds to the top of the goroutine and terminates the whole process rather than the single connection:

// pkg/ssh/server.go:226
go s.handleNewChannel(newChannel, extraPayloadCh)    // no recover anywhere in the chain

The sink is reachable without credentials in the default configuration. When no authorized-keys file is set, the gateway disables SSH client authentication, which is the default and documented mode where users authenticate through the frp token embedded in the SSH command. The exec request is processed during the channel phase, before that token is validated, so an unauthenticated peer reaches the sink:

// pkg/ssh/gateway.go:74
sshConfig.NoClientAuth = cfg.AuthorizedKeysFile == ""  // default: no client auth

Affected product: frp (fatedier), frps server, SSH Tunnel Gateway Affected versions: v0.53.0 (when the gateway was introduced) through v0.70.0, confirmed against a v0.70.0 build

PoC

The SSH Tunnel Gateway must be enabled with no authorized-keys file, which is the default mode of any deployment that turns the gateway on. No credentials and no knowledge of the target are required.

Enable the gateway on a stock v0.70.0 build:

bindPort = 7000

[sshTunnelGateway]
bindPort = 2200

As an unauthenticated SSH client, open a session channel and send one exec request whose four-byte length prefix is 0xFFFFFFFF followed by a single byte, giving the five-byte payload ff ff ff ff 41. The server immediately panics and exits:

panic: runtime error: slice bounds out of range [4:3]
...github.com/fatedier/frp/pkg/ssh.(*TunnelServer).handleNewChannel
    .../frp/pkg/ssh/server.go:319

The shell prompt returns in the server terminal, confirming the whole process has terminated and every other client tunnel is dropped at the same instant. A well-formed request of the same length (prefix 1) leaves the server running, proving the crash is caused by the overflow value and not by the exec request itself. The attacker can re-send the payload after any restart to hold the server down indefinitely.

Impact

This is an unauthenticated remote denial of service (CWE-190) leading to an out-of-range array index (CWE-129) and an unhandled process crash (CWE-755). A single five-byte, credential-free message kills the entire frps process. Because one frps commonly multiplexes the tunnels of many clients, the crash drops every active tunnel for every tenant at once and new logins are refused until the process is restarted, and re-sending the payload after each restart keeps the service down indefinitely (CWE-400). There is no confidentiality or integrity impact and no code execution.

This issue only affects frps instances with the SSH tunnel gateway explicitly enabled. The SSH tunnel gateway is disabled by default and is not commonly used in typical frps deployments. Default frps configurations are not affected.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.70.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fatedier/frp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.53.0"
            },
            {
              "fixed": "0.70.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-129",
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:48:04Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAn integer-overflow vulnerability in the frp server\u0027s optional SSH Tunnel Gateway lets any unauthenticated remote attacker crash the entire `frps` process with a single five-byte message. When the gateway parses an SSH `exec` channel request in `pkg/ssh/server.go`, it adds a small constant to a four-byte length value taken directly from the request. Because that length is fully attacker-controlled, a value of `0xFFFFFFFF` makes the addition wrap around to a tiny number, defeating the only bounds check and forcing an out-of-range slice. Go raises a panic that nothing recovers, so the whole server exits. In the default gateway mode SSH clients are not authenticated and the request is handled before any frp token is checked, so the crash is reachable pre-authentication. It carries no state and is trivially repeatable, turning one crash into a sustained outage that drops every tunnel for every user.\n\n## Details\n\nThe `exec` request payload is a four-byte big-endian length followed by that many command bytes, and the length field is fully attacker-controlled. The gateway computes the end of the command as `4 + length`. The constant `4` takes the `uint32` type of the length field, so `4 + 0xFFFFFFFF` wraps modulo 2^32 to `3`. The only guard compares the real payload size against this wrapped value, so a five-byte payload passes the test `5 \u003c 3`, and the slice runs from index 4 to index 3:\n\n```go\n// pkg/ssh/server.go:315-319\nend := 4 + binary.BigEndian.Uint32(req.Payload[:4])  // 4 + 0xFFFFFFFF wraps to 3\nif len(req.Payload) \u003c int(end) {                     // 5 \u003c 3 is false, so it passes\n    continue\n}\nextraPayload := string(req.Payload[4:end])           // payload[4:3] -\u003e panic\n```\n\nThe handler runs in a bare goroutine and no function in the call chain installs a `recover`, so the panic unwinds to the top of the goroutine and terminates the whole process rather than the single connection:\n\n```go\n// pkg/ssh/server.go:226\ngo s.handleNewChannel(newChannel, extraPayloadCh)    // no recover anywhere in the chain\n```\n\nThe sink is reachable without credentials in the default configuration. When no authorized-keys file is set, the gateway disables SSH client authentication, which is the default and documented mode where users authenticate through the frp token embedded in the SSH command. The `exec` request is processed during the channel phase, before that token is validated, so an unauthenticated peer reaches the sink:\n\n```go\n// pkg/ssh/gateway.go:74\nsshConfig.NoClientAuth = cfg.AuthorizedKeysFile == \"\"  // default: no client auth\n```\n\nAffected product: frp (fatedier), `frps` server, SSH Tunnel Gateway\nAffected versions: v0.53.0 (when the gateway was introduced) through v0.70.0, confirmed against a v0.70.0 build\n\n## PoC\n\nThe SSH Tunnel Gateway must be enabled with no authorized-keys file, which is the default mode of any deployment that turns the gateway on. No credentials and no knowledge of the target are required.\n\nEnable the gateway on a stock v0.70.0 build:\n\n```toml\nbindPort = 7000\n\n[sshTunnelGateway]\nbindPort = 2200\n```\n\nAs an unauthenticated SSH client, open a session channel and send one `exec` request whose four-byte length prefix is `0xFFFFFFFF` followed by a single byte, giving the five-byte payload `ff ff ff ff 41`. The server immediately panics and exits:\n\n```text\npanic: runtime error: slice bounds out of range [4:3]\n...github.com/fatedier/frp/pkg/ssh.(*TunnelServer).handleNewChannel\n    .../frp/pkg/ssh/server.go:319\n```\n\nThe shell prompt returns in the server terminal, confirming the whole process has terminated and every other client tunnel is dropped at the same instant. A well-formed request of the same length (prefix `1`) leaves the server running, proving the crash is caused by the overflow value and not by the `exec` request itself. The attacker can re-send the payload after any restart to hold the server down indefinitely.\n\n## Impact\n\nThis is an unauthenticated remote denial of service (CWE-190) leading to an out-of-range array index (CWE-129) and an unhandled process crash (CWE-755). A single five-byte, credential-free message kills the entire `frps` process. Because one `frps` commonly multiplexes the tunnels of many clients, the crash drops every active tunnel for every tenant at once and new logins are refused until the process is restarted, and re-sending the payload after each restart keeps the service down indefinitely (CWE-400). There is no confidentiality or integrity impact and no code execution.\n\nThis issue only affects frps instances with the SSH tunnel gateway explicitly enabled. The SSH tunnel gateway is disabled by default and is not commonly used in typical frps deployments. Default frps configurations are not affected.",
  "id": "GHSA-26gq-p25f-99cp",
  "modified": "2026-07-24T21:48:04Z",
  "published": "2026-07-24T21:48:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fatedier/frp/security/advisories/GHSA-26gq-p25f-99cp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fatedier/frp/pull/5428"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fatedier/frp/commit/7dc7be930e2452ae93fd32f2a77f8c6fcd0b652b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fatedier/frp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fatedier/frp/releases/tag/v0.70.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "frp: Unauthenticated Remote Denial of Service in the frp SSH Tunnel Gateway via Integer Overflow"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…