Unauthenticated CPU DoS in wolfSSH Server via DH Group Exchange Messages
CVSS 4.0
6.9medium
EPSS
—
Published
()
Modified
AI analysis
wolfSSH's IsMessageAllowedServer() in src/internal.c applies no direction check to key exchange message IDs 30-34, so an unauthenticated client can send server-to-client messages that a server should never accept. By negotiating diffie-hellman-group-exchange-sha256 and then sending SSH_MSG_KEX_DH_GEX_GROUP (31), the client tricks the server into running the client-role handler DoKexDhGexGroup(), which performs two 8-round Miller-Rabin primality tests on attacker-supplied values of up to 8192 bits, generates a DH key pair in the attacker's group, and replies with SSH_MSG_KEX_DH_GEX_INIT (32). This yields a low-overhead CPU denial-of-service on the server, since published RFC 3526 safe primes are free for the attacker to obtain and are the worst-case input. The primality-check cost applies to 1.5.0 (where validation was added); versions 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. There is no known public PoC or in-the-wild exploitation, and the issue is not on the CISA KEV list; a fixed release (1.6.0) has shipped alongside other wolfSSH security fixes.
What to do: Upgrade to wolfSSH 1.6.0, the release that ships security fixes including this one. If upgrading is not immediately possible, rebuild with WOLFSSH_NO_DH_GEX_SHA256 (or WOLFSSH_NO_DH / NO_SHA256) to compile out the affected code path, or restrict key exchange negotiation to exclude diffie-hellman-group-exchange-sha256. Watch for unauthenticated clients causing sustained CPU spikes on SSH endpoints, which would indicate attempted exploitation.
Affected
wolfSSL wolfSSH
1.5.0 (primality-test DoS cost); 1.2.0 through 1.4.22 (same message admitted, client-role path entered without primality cost); described as affecting wolfSSH t
Estimated exposure
unknown — plausibly thousands to tens of thousands of embedded devices, but not reliably countable — wolfSSH is an SSH server library compiled into embedded/IoT and industrial firmware rather than a standalone installable product, and its SSH banners are not distinguishable in public internet scans, so there is no solid count of exposed…
Description
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.
wolfSSL's wolfSSH 1.6.0 patches five flaws, including a critical ECDSA host-key authentication bypass.
wolfSSL released wolfSSH 1.6.0 on October 6, 2026, fixing five vulnerabilities in versions through 1.5.0. CVE-2026-16516 (CVSS v4 9.0) lets an active man-in-the-middle attacker bypass ECDSA host-key checks when a permissive validation callback is used. CVE-2026-83540 (CVSS 7.7) can let a lower-privileged Windows wolfSSHd user reuse another user's logon token. Three medium issues cover Diffie-Hellman CPU exhaustion (CVE-2026-84897), unauthorized TCP forwarding (CVE-2026-81535), and a one-byte SFTP path overflow (CVE-2026-83742). The release also enables strict key exchange by default against the Terrapin attack (CVE-2023-48795).
wolfSSL released wolfSSH 1.6.0, fixing five flaws including a critical SSH host-key verification bypass.
wolfSSL published wolfSSH 1.6.0 on October 6, 2026, patching five vulnerabilities affecting versions through 1.5.0: one critical, one high, and three medium. Critical CVE-2026-16516 lets a man-in-the-middle replace the server ECDSA host key with a different curve so signature checks succeed, but only if the application uses a weak public-key-checking callback. High-severity CVE-2026-83540 affects Windows wolfSSHd 1.4.15 through 1.5.0, where shared logon tokens can give one authenticated user another account’s identity. The remaining flaws are unauthenticated Diffie-Hellman group-exchange CPU abuse (CVE-2026-84897), policy-bypass TCP forwarding (CVE-2026-81535), and an authenticated SFTP NUL overflow (CVE-2026-83742); 1.6.0 also enables strict key exchange and 2048-bit minimum RSA user keys.