wolfSSH 1.6.0 fixes five security flaws

What happened

wolfSSL published wolfSSH 1.6.0 on GitHub on 6 October 2026 (late evening UTC). The release notes and wolfSSL's security vulnerabilities page list five CVEs fixed in this version, and the CVE records went public on 7 October 2026. wolfSSL is the CNA for all five and scored them with CVSS 4.0.

The two headline issues match the post. CVE-2026-16516 (Critical, 9.0) is an ECDSA host key validation flaw that can let a man-in-the-middle impersonate an SSH server to a wolfSSH client. CVE-2026-83540 (High, 7.7) is a Windows wolfSSHd authentication flaw where concurrent connections shared one logon token, so a user could end up logged in as another, more privileged user. The three medium issues have their own CVE IDs: CVE-2026-84897 (key exchange, 6.9), CVE-2026-81535 (TCP forwarding, 6.3) and CVE-2026-83742 (SFTP path handling, 5.3).

Who is affected

Affected versions differ per CVE. CVE-2026-16516 affects wolfSSH through 1.5.0 on all platforms, on the client side. CVE-2026-83540 affects only wolfSSHd on Windows, from 1.4.15 through 1.5.0; non-Windows builds are unaffected. CVE-2026-84897 affects servers from 1.2.0 through 1.5.0, with the CPU cost from 1.5.0, and builds with WOLFSSH_NO_DH_GEX_SHA256 are unaffected. CVE-2026-81535 affects 1.4.8 through 1.5.0 builds with --enable-fwd. CVE-2026-83742 affects 1.4.11 through 1.5.0 on non-Windows platforms.

wolfSSH is an embedded SSH library, so many deployments are inside firmware and products rather than standalone servers. Vendors that ship wolfSSH in devices need to rebuild with 1.6.0, and their customers depend on those vendor updates.

What is confirmed

For CVE-2026-16516, wolfSSL says wolfSSH did not check that the ECDSA curve in a server's host key blob matched the negotiated algorithm, so a man-in-the-middle could substitute a key on another curve and pass verification with its own private key. The CVE record says exploitation requires an active MitM position and a lax public key check callback, giving trust on first use, a check on the algorithm name only, or a fingerprint match against the parsed key as examples. The CNA vector is CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N and the CWE is CWE-345. Credit goes to zhangph (GitHub afldl), and the fix is PR #1022, which was merged on 16 June 2026 and first shipped in 1.6.0.

For CVE-2026-83540, wolfSSL says wolfSSHd on Windows shared one authentication context and its logon token across concurrent connections, and both password and public key logins wrote to it. The CVE record describes a race in which a token is not released before the next connection acquires one, letting a less privileged user with a valid account force a login as a more privileged user. The vector is CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N and the CWEs are CWE-287 and CWE-613. wolfSSL found it through internal testing and fixed it in PR #1163.

The three medium issues are as follows:

• CVE-2026-84897: an unauthenticated client can send server-only DH group exchange messages. This makes the server run expensive primality tests on attacker-chosen groups of up to 8192 bits and continue the key exchange in the client role.
• CVE-2026-81535: with forwarding enabled, forwarded-tcpip channel opens bypassed the forwarding policy callback. A client also accepted forwards it never requested, so a peer could make an endpoint allocate buffers for unauthorized channels.
• CVE-2026-83742: an authenticated SFTP user can send a crafted path that writes one NUL byte past a stack buffer in wolfSSH_RealPath() on non-Windows builds and crashes the process.

None of the five is in the CISA KEV catalog. CISA-ADP SSVC records exploitation as none for all five. ThreatWire found no public proof-of-concept repository. The GitHub advisories are unreviewed, and NVD lists the records as Undergoing Analysis with only wolfSSL's scores.

What is not confirmed

wolfSSL does not report exploitation in the wild for any of these CVEs. The post's "certain man-in-the-middle scenarios" for CVE-2026-16516 is accurate but leaves out the second condition, a lax host key check callback in the client application. Clients that compare the full expected host key are not described as affected. NVD has not published its own scores, and CISA-ADP has added no CVSS, so every score here is wolfSSL's.

The original report for CVE-2026-16516, GitHub issue #1012, was public from 10 June 2026 and describes the flaw technically. ThreatWire does not treat that issue as a proof of concept. The post does not mention that CVE-2026-83540 needs a valid account and concurrent connections, or that CVE-2026-83742 needs an authenticated SFTP session.

What to do

Upgrade to wolfSSH 1.6.0 or later, and ask device vendors that embed wolfSSH for firmware built on 1.6.0. The release also changes defaults, including strict KEX on by default, a 2048-bit minimum for DH group exchange and RSA user keys, and a limit of six failed authentication attempts. Review the release notes before rebuilding.

Until you can upgrade, wolfSSH client applications should verify the full expected server host key rather than relying on trust on first use, algorithm-name checks or parsed-key fingerprints. Windows wolfSSHd operators should restrict access to trusted accounts and review session logs for logins whose identity does not match the authenticating user. Disable TCP forwarding if it is not needed. Where practical, limit pre-authentication exposure of wolfSSH servers to trusted networks.

Sources: wolfSSL security vulnerabilities page, wolfSSH 1.6.0 release notes on GitHub, NVD and CVE.org records with CISA-ADP data, GitHub advisories, and the CISA KEV catalog.