github.com/fatedier/frp known bugs

## 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: ```go // 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: ```go // 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: ```go // 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: ```toml 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: ```text 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.

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

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