SSH Forwarding Authorization Bypass in wolfSSH ≤ 1.5.0 Enables Unbounded Memory Use
AI analysis
wolfSSH through 1.5.0, when built with the non-default --enable-fwd option, applies its forwarding-policy callback only to direct-tcpip channel opens: forwarded-tcpip channel opens from an SSH peer are admitted with no authorization check and no cap on how many may be created. A malicious SSH client can therefore open unlimited forwarding channels against a wolfSSH server, each allocating per-channel buffers that exhaust memory and can degrade or crash the endpoint. Conversely, a malicious server can open forwarded-tcpip channels on a wolfSSH client for addresses and ports the client never registered with a tcpip-forward request, violating RFC 4254 section 7.2 and abusing the client as an unauthorized relay to hosts and services the user never permitted. Any product embedding wolfSSH 1.5.0 or earlier compiled with forwarding enabled is affected on both the server and client side; the flaw is fixed in wolfSSH 1.6.0. No public proof of concept is known, the CVE is not on the CISA KEV list, and no exploitation has been reported.
What to do: Upgrade to wolfSSH 1.6.0, which fixes this flaw along with four others including a critical MITM host-key verification bypass. If you cannot upgrade immediately, rebuild wolfSSH without --enable-fwd to remove the vulnerable forwarding code path, or restrict which peers can reach the SSH endpoint and watch for unexpected forwarded-tcpip channel opens. Audit your build configuration first: default builds without forwarding enabled are not affected by this issue.
Affected
| wolfSSL wolfSSH | through 1.5.0, only when built with --enable-fwd (fixed in 1.6.0) |
Estimated exposure
nichelikely hundreds to a few thousand forwarding-enabled deployments (rough order-of-magnitude estimate; no public telemetry exists) — wolfSSH is a niche embedded SSH library and only builds compiled with the opt-in --enable-fwd flag are vulnerable, so the affected population is a small subset of wolfSSH users; there are no public install counts or internet-scan…
Description
In wolfSSH through 1.5.0 built with --enable-fwd, DoChannelOpen() in src/internal.c gates only direct-tcpip channel opens with the forwarding policy callback. forwarded-tcpip opens are admitted without an authorization check and are not capped in number, allowing a malicious SSH peer to make an endpoint allocate unbounded per-channel buffers for forwarding channels the application never authorized. A client also does not check a forwarded-tcpip open against the forwards it registered with a tcpip-forward request, as RFC 4254 section 7.2 requires, so a malicious server can open forwarding channels for addresses and ports the client never asked it to forward.