wolfSSH Patches 5 Security Vulnerabilities, Including Critical SSH Authentication Bypass

wolfSSL has released wolfSSH version 1.6.0, which addresses five security vulnerabilities, including a critical flaw that could allow a man-in-the-middle attacker to bypass SSH host-key authentication under certain deployment conditions.

The release, dated October 6, 2026, fixes CVE-2026-16516, a critical ECDSA host-key validation issue affecting wolfSSH up to version 1.5.0.

Additionally, it resolves a high-severity flaw related to Windows authentication contexts and three medium-severity issues involving Diffie-Hellman key exchange, TCP forwarding authorization, and SFTP path handling.

wolfSSH Patches 5 Security Vulnerabilitie

The critical vulnerability, identified as CVE-2026-16516, arises from wolfSSH’s failure to verify that the ECDSA curve in a server host-key blob matched the algorithm negotiated during the key exchange.

An active network attacker positioned between the client and server could present an ECDSA key on a different curve and sign the exchange using a private key they control.

Because the vulnerable code imported the substituted key without confirming that the curve matched the negotiated host-key algorithm, signature verification could succeed despite the manipulation.

Successful exploitation requires the attacker to be in an active man-in-the-middle position and for the system to employ a permissive host-key validation callback, such as trust-on-first-use implementations, algorithm-name-only checks, or callbacks that compare a fingerprint derived from the parsed key.

GitHub rates the vulnerability on critical, with a CVSS v4 score of 9.0, and classifies it under CWE-345 for insufficient verification of data authenticity.

wolfSSH version 1.6.0 also addresses CVE-2026-83540, a high-severity flaw specific to wolfSSHd on Windows systems. The Windows daemon improperly shared an authentication context and Windows logon token across concurrent connections.

As a result, a lower-privileged user with valid credentials could potentially trigger an authentication event that reused another user’s more privileged token, effectively granting elevated rights.

Both password and public-key authentication paths could allow this shared token to be written. This issue affects wolfSSH versions 1.4.15 through 1.5.0, while non-Windows builds remain unaffected. The flaw has a CVSS v4 score of 7.7 and is categorized as improper authentication (CWE-287).

The release additionally addresses:

• CVE-2026-84897: A malicious unauthenticated client could send server-side Diffie-Hellman Group Exchange messages to a vulnerable wolfSSH server. This could force costly primality testing on attacker-controlled parameters, creating a CPU-exhaustion condition. It affects versions 1.2.0 through 1.5.0; builds compiled with WOLFSSH_NO_DH_GEX_SHA256 are unaffected.
• CVE-2026-81535: When compiled with --enable-fwd, wolfSSH could accept unauthorized forwarded-tcpip channel opens without consulting the forwarding-policy callback. A peer could cause endpoints to allocate buffers for forwarding channels the application had not authorized.
• CVE-2026-83742: A flaw in wolfSSH_RealPath() on non-Windows systems could cause an unsigned-length calculation to wrap after a path exceeded a threshold, leading to a one-byte stack buffer overflow via a crafted authenticated SFTP path. Applications directly calling the public function with an output buffer smaller than their input face additional exposure.

In addition to fixing these vulnerabilities, version 1.6.0 enables strict key exchange by default, protecting against the Terrapin SSH prefix-truncation attack (CVE-2023-48795).

The release also raises the minimum required Diffie-Hellman group exchange size to 2048 bits, requires RSA authentication keys to be at least 2048 bits, limits failed authentication attempts to six by default, and enforces StrictModes for wolfSSHd.

Administrators are encouraged to upgrade to wolfSSH 1.6.0, prioritize remediation for internet-exposed clients and Windows wolfSSHd deployments, review custom host-key verification callbacks, and ensure that applications remain compatible with stricter cryptographic and API behavior.

Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.