CVE-2026-84897
MediumCVSS 6.9Summary
A vulnerability in wolfSSH up to version 1.5.0 allows an unauthenticated client to send Diffie-Hellman group exchange messages (SSH_MSG_KEX_DH_GEX_GROUP and SSH_MSG_KEX_DH_GEX_REPLY) to a server, which fails to check the direction of these messages. The server then runs a client-side handler, leading to expensive Miller-Rabin primality tests on attacker-controlled data and generating a key pair in an attacker-chosen group.
Risk Assessment
The risk includes potential server overload due to expensive computations and possible compromise of SSH session security, as the server uses a Diffie-Hellman group supplied by the attacker, which may enable man-in-the-middle attacks or weaken key negotiation.
Recommendation
It is recommended to immediately upgrade wolfSSH to a version newer than 1.5.0 if available, or apply a workaround such as disabling support for diffie-hellman-group-exchange-sha256 (by defining WOLFSSH_NO_DH_GEX_SHA256) in the build configuration.
Other vulnerabilities in wolfSSH
See all- CVE-2026-83742Medium
Unsigned integer underflow in wstrncat() in src/port.c in wolfSSL wolfSSH from v1.4.11 through v1.5.0 on non-Windows platforms allows an authenticated remote attacker to write one out-of-bounds null byte past the end of a stack buffer by sending a crafted SFTP path. wolfSSH_RealPath() in src/ssh.c appends each path component with a remaining-size bound (outSz - curSz) rather than the full destination size, so once the accumulated path reaches half the output buffer the size_t computation n - strlen(s1) - 1 wraps to near SIZE_MAX. The strncat() call is then effectively unbounded and copies the whole component; when that component exactly fills the remainder of the buffer, its terminating null is written one byte past the end. The caller's own length check keeps the copied data inside the buffer, so the overflow is limited to that single null byte, which may corrupt an adjacent stack value and crash the process. Applications that call the public wolfSSH_RealPath() with an output buffer smaller than the input path are additionally exposed to an unbounded copy, because the word32 expression outSz - segSz in that length check also wraps.
- CVE-2026-81535Medium
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.
- CVE-2026-16516Critical
wolfSSH does not validate that the ECDSA curve identifier in a KEXDH_REPLY host key blob matches the algorithm negotiated during key exchange. An active man-in-the-middle attacker can substitute a host key blob containing a different ECDSA curve, causing the client to import the key on the wrong curve, and because the attacker controls the private key for the substituted curve, signature verification passes.
- CVE-2025-14942Critical
wolfSSH's key exchange state machine can be manipulated to leak the client's password in the clear, trick the client to send a bogus signature, or skip user authentication. This affects client applications with wolfSSH version 1.4.21 and earlier.
- CVE-2025-15382High
A heap buffer over-read vulnerability exists in the wolfSSH_CleanPath() function in wolfSSH. An authenticated remote attacker can trigger the issue via crafted SCP path input containing '/./' sequences, resulting in a heap over read by 1 byte.
Original NVD description (English source)
src/internal.c in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange messages SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33) when a server receives them from an unauthenticated client. IsMessageAllowedServer() applies no direction check to the key exchange message range: when the peer is keying and no particular message is expected, which is the state a server is in for the whole window after it processes the client's KEXINIT because nothing sets handshake->expectMsgId there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that admits every message id from 30 through 34. A client that negotiates diffie-hellman-group-exchange-sha256 and then sends message 31 makes the server run the client-side handler DoKexDhGexGroup(), which validates the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on p and one on (p-1)/2, on a value of up to 8192 bits. The handler then returns success: the server stores the attacker's prime and generator, generates a Diffie-Hellman key pair in the attacker's group, and sends the client-role message SSH_MSG_KEX_DH_GEX_INIT (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public key check callback is registered, so it carries no comparable cost. Builds that define WOLFSSH_NO_DH_GEX_SHA256, which is implied by WOLFSSH_NO_DH or NO_SHA256, are unaffected.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

