wolfSSH 1.6.0 Fixes Critical CVEs: Windows wolfSSHd Privilege Risk and Upgrade Guide

What wolfSSH is and where it runs​

wolfSSL describes wolfSSH as a small, fast, portable SSH implementation, including support for SCP and SFTP. It includes SSH client libraries and an SSH server implementation, and allows for password and public key authentication.

The library is aimed at embedded developers, so it often sits inside firmware, appliances and vendor tools rather than showing up as an obvious install. A Windows admin may never have chosen wolfSSH and still have it running in a management appliance, an industrial gateway, or an SFTP feature in a vendor product.

Section summary: wolfSSH is usually bundled inside other products, so it can be hard to find.

The five CVEs​

CVE aggregator Strix publishes CVSS scores taken from the CNA advisories filed through CVE.org. Its numbers match the SecNews report: 9.0, 7.7, 6.9, 6.3 and 5.3. Strix also notes that NVD analysis is still pending for each entry. wolfSSL's own table gives severity labels only, not scores.

CVE-2026-16516: ECDSA curve mismatch (critical)​

According to wolfSSL, 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 a private key of its own. The CVE record locates the bug in the KEXDH_REPLY message: wolfSSH does not validate that the ECDSA curve identifier in a KEXDH_REPLY host key blob matches the algorithm negotiated during key exchange.

The attack has one important precondition. It also requires a lax public key check callback. wolfSSH leaves host-key trust decisions to the application that embeds it. If that application's callback compares the full expected key, the substitution should fail. If it accepts any new key, or checks only part of the key, an attacker in the middle can pose as the server.

That means a 9.0 score does not mean every wolfSSH client is exposed. It does mean you can't judge exposure without reading the host-key callback code.

CVE-2026-83540: Windows wolfSSHd login poisoning (high)​

This is the bug Windows shops should look at first. wolfSSL says wolfSSHd on Windows shared one authentication context, and the logon token stored in it, across concurrent connections, so a user with a valid account could end up logged in as another, more privileged user. Password and public key logins both wrote the shared token. The CVE record describes the same flaw as follows: the Windows logon token acquired for one authenticated connection is not released before a token is acquired for a subsequent connection, resulting in user login poisoning between connections.

The bug has existed since the Windows port first shipped. It was introduced with the initial Windows port of wolfSSHd in wolfSSH version 1.4.15 and affects all versions through 1.5.0. Non-Windows builds are unaffected.

Exploiting it requires a valid account, but any low-privilege account will do. On a server where several accounts log in concurrently, one of them could end up running with administrator rights. SecNews suggested limiting which accounts may log in as a stopgap. That narrows exposure but does not fix the bug.

CVE-2026-84897: CPU exhaustion before authentication (medium)​

Here a server could be made to act like a client. A wolfSSH server accepted the DH group exchange messages only a server sends, SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33), from an unauthenticated client. A client that negotiated diffie-hellman-group-exchange-sha256 and then sent message 31 caused the server to run the client-side handler. That handler primality-tests an attacker-chosen group of up to 8192 bits, about half a second of CPU per 1 KB packet for a 4096-bit prime. The server then continued the key exchange in the client role.

SecNews cited a worst case of 5.8 seconds per packet with 8,192-bit numbers. wolfSSL's own summary uses the half-second figure at 4,096 bits, so treat the larger number as unconfirmed. Half a second per kilobyte is still a lot of work for one small, unauthenticated packet, especially on embedded CPUs.

The affected range is 1.2.0 through 1.5.0, but the primality cost applies from 1.5.0. Builds with WOLFSSH_NO_DH_GEX_SHA256 are unaffected. Disabling diffie-hellman-group-exchange-sha256 where you don't need it is a reasonable interim measure. SecNews notes that lowering the maximum group size only reduces the processing cost; the server still accepts the message.

CVE-2026-81535: unauthorized forwarding channels (medium)​

This one applies only to builds compiled with port forwarding. With --enable-fwd, forwarded-tcpip channel opens were admitted without consulting the forwarding policy callback, and a client accepted them for forwards it never requested. The CVE text adds that a client 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. wolfSSL says the result is that a peer can make an endpoint allocate buffers for forwarding channels the application never authorized. SecNews describes this as a route to resource exhaustion. Affected versions are 1.4.8 through 1.5.0.

CVE-2026-83742: one-byte stack write in SFTP path handling (medium)​

The CVE record describes an 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. wolfSSL traces it to wolfSSH_RealPath(), which sized each appended path component against the remaining buffer space instead of the buffer's total size. Once the path passed the halfway point, the length calculation wrapped around. The vendor says the stray null byte can corrupt an adjacent value and crash the process.

wolfSSL also warns developers that applications calling the public wolfSSH_RealPath() with an output buffer smaller than the input face an unbounded copy, which is more serious than a one-byte write.

Section summary: One bug is critical only when paired with weak host-key checking, one is a Windows-only privilege problem, and three depend on specific build options or features.

What to do now​

1. Find every copy. Look in appliances, firmware images, vendor SFTP tools and statically linked binaries. The same library can show up in products from several vendors. Ask suppliers directly if you can't inspect the build.
2. Record version, OS and build flags. Exposure depends on them: Windows vs. non-Windows, --enable-fwd, and whether WOLFSSH_NO_DH_GEX_SHA256 was set.
3. Prioritize by exposure, not CVSS alone:
   • Clients using ECDSA host keys with permissive verification callbacks
   • Windows wolfSSHd servers that accept concurrent logins from multiple accounts
   • Internet-facing servers that negotiate DH group exchange
   • Builds with forwarding enabled
   • Non-Windows SFTP servers, and any code that calls wolfSSH_RealPath() directly
4. Upgrade to 1.6.0. wolfSSL lists it as the fix for all five CVEs. If you get wolfSSH through an OEM, ask for its patched firmware or package and test it before rollout.
5. Use mitigations as stopgaps only. Restricting logins on Windows wolfSSHd and turning off unneeded group exchange reduce risk until you can update. Neither replaces the patch.

Analysis​

wolfSSL has published detailed write-ups for each CVE, including affected version ranges, preconditions and pull request numbers, which is more than many vendors provide. The SecNews report, by contrast, ends with a VPN affiliate pitch. That doesn't affect the vulnerability facts, but it was published while the product page still showed 1.5.0, and its upgrade advice was overtaken by the release on GitHub.

The bigger risk is the usual one for embedded libraries: the fix exists, but it reaches devices only when each downstream vendor ships it. For CVE-2026-83540 on Windows, that wait means any valid low-privilege account could end up with administrator rights. If you can't see what's running inside your appliances, now is a good time to ask vendors for SBOMs (software bills of materials).

None of the sources reviewed report exploitation in the wild.