wolfSSH Authentication and Protocol Flaws

Host key substitution in wolfSSH clients using ECDSA host keys lets an unauthenticated, network-positioned attacker have the client import an attacker-chosen public key, because ParseECCPubKey() derives the curve from the untrusted KEXDH_REPLY blob rather than from the negotiated host key algorithm, so the attacker's own signature over the substituted key verifies successfully. Exploitation is doubly gated: the attacker must hold an active man-in-the-middle position able to rewrite the key exchange reply, and the client must be deployed with a lax public-key verification callback such as trust-on-first-use, an algorithm-name-only check, or fingerprint matching performed against the already-parsed key. No public exploit code has been identified at time of analysis; the vendor's CVSS 4.0 score of 9.0 (Critical) overstates realistic urgency for most fleets, and our independent assessment maps the same defect to CVSS 3.1 7.4 (High) with AC:H.

Windows logon token reuse in wolfSSHd versions 1.4.15 through 1.5.0 allows an authenticated low-privilege user to impersonate a higher-privileged user by exploiting a failure to release the Windows logon token between authenticated connections. Only the Windows port is affected; non-Windows builds are explicitly unaffected. Exploitation depends on a timing overlap with a privileged user's login (assessed as a race condition, AT:P in CVSS 4.0 and AC:H in the independent CVSS 3.1 assessment), and no public exploit identified at time of analysis. Upstream fix commits are available and the vendor advisory is published; severity is assessed as High (CVSS 4.0 7.7).

Pre-authentication CPU exhaustion affects wolfSSH servers through 1.5.0 that are built with Diffie-Hellman group-exchange SHA256 support, letting a remote unauthenticated client force the server to execute client-role key-exchange logic. After negotiating diffie-hellman-group-exchange-sha256, the attacker sends SSH_MSG_KEX_DH_GEX_GROUP (31) - a message only a client should send - and the server runs the client-side handler DoKexDhGexGroup(), performing two 8-round Miller-Rabin primality tests on an attacker-supplied prime of up to 8192 bits and then generating a Diffie-Hellman key pair in the attacker's group. The flaw yields only availability impact (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) with no memory corruption or data exposure; no public exploit code has been identified at time of analysis and it is not confirmed as actively exploited.

wolfSSH through 1.5.0, when compiled with the --enable-fwd (WOLFSSH_FWD) TCP/IP forwarding option, fails to apply its forwarding policy callback or any channel-count cap to incoming forwarded-tcpip channel opens, so a malicious SSH peer can force unbounded per-channel buffer allocation and exhaust endpoint memory. The same code path leaves wolfSSH clients validating nothing: a forwarded-tcpip open is not checked against the forwards the client actually registered via tcpip-forward, contrary to RFC 4254 section 7.2, and a server should never receive a forwarded-tcpip open at all. Impact is limited to availability (memory exhaustion, assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L; vendor CVSS 4.0 base 6.3), the forwarding feature must be explicitly enabled at build time, and no public exploit code was identified at time of analysis. No vendor-released tagged fix version is confirmed from the provided data; upstream patch commits exist.

An authenticated remote attacker with a valid SSH session can trigger a one-byte out-of-bounds stack write in wolfSSH v1.4.11 through v1.5.0 on non-Windows platforms by sending a crafted SFTP path, which can corrupt an adjacent stack value and crash the server process. The flaw is an unsigned integer underflow (CWE-191) in which the pointer/length math in wolfSSH_RealPath() and wstrncat() wraps once the accumulated path reaches roughly half the output buffer, causing a terminating null byte to be written one byte past the end of the stack buffer. The impact is limited to a single-byte corruption causing denial of service rather than arbitrary write or code execution, and no public exploit has been identified at time of analysis; a separate, more severe unbounded-copy condition exists only for third-party applications that call the public wolfSSH_RealPath() API with an output buffer smaller than the input path.