Vulnerabilities
wolfSSH 1.6.0 fixes five flaws in embedded SSH
wolfSSH 1.6.0 fixes a critical host key check flaw, a Windows login mix-up and three more bugs. Who is exposed, how each works, and what to change.
wolfSSL released wolfSSH 1.6.0 on October 6, 2026, and published five CVEs against the library the next day. The most serious, CVE-2026-16516 (CVSS 4.0 score 9.0, critical), lets a man-in-the-middle pass itself off as the SSH server a wolfSSH client is connecting to. A second, CVE-2026-83540 (7.7, high), lets a user with a valid account on a Windows wolfSSHd server end up logged in as a more privileged user. Every release through 1.5.0 carries at least one of the five.
wolfSSH is a small SSHv2 client and server library in C, written for firmware rather than servers. It ships as a Zephyr RTOS module, an Espressif ESP-IDF component and a Renesas partner package for RA, RX and RZ microcontrollers, and runs on VxWorks. If your product, or a device you buy, offers SSH or SFTP from a microcontroller or RTOS, check with the vendor whether that stack is wolfSSH. Desktop and server systems running OpenSSH are not affected. None of the five is known to be exploited, and CISA's assessment on the NVD records lists exploitation as "none".
How the critical flaw works
During an SSH key exchange the server sends its host key inside the KEXDH_REPLY message, and signs the exchange with the matching private key. The client is meant to check two things: that the signature verifies against that key, and that the key is the one it expects for this server. The second check happens in the application, through a public key check callback that wolfSSH calls with the received key.
For ECDSA host keys, the key blob names its curve twice: once in the algorithm string (for example ecdsa-sha2-nistp256) and once in a separate curve identifier defined by RFC 5656. In ParseECCPubKey() in src/internal.c, wolfSSH took the curve from the blob's own algorithm string and skipped the curve identifier without reading it. It never compared either against the host key algorithm the two sides had just negotiated. An attacker sitting on the network path can therefore send a host key on a different curve, sign with their own private key for it, and the signature checks out.
That only becomes a full server impersonation if the application's callback is lax. The CVE names three lax patterns: trust on first use (accept any key the first time), checking only the algorithm name, and matching a fingerprint computed from the parsed key. Where one of those applies, the attacker sees and can change everything in the session, including passwords the client sends.
The Windows login mix-up
CVE-2026-83540 affects only the Windows port of wolfSSHd, the SSH server daemon that ships with the library. When a user logs in with a password or public key, wolfSSHd gets a Windows logon token for that account and runs the session under it. Before 1.6.0 the daemon kept that token in an authentication context shared across connections, and did not release one connection's token before the next login wrote its own. When connections overlapped, a session could run under another user's token. A low-privileged user with a valid account could use that to get a session as an administrator who logged in around the same time.
The bug arrived with the first Windows port in 1.4.15 and runs through 1.5.0. wolfSSL found it in its own testing. Linux and RTOS builds of wolfSSHd are not affected.
The three medium flaws
CVE-2026-84897 (6.9). A server accepted two key exchange messages that only a server should send, SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33), from an unauthenticated client. A client that negotiates diffie-hellman-group-exchange-sha256 and sends message 31 makes the server run its client-side code: it primality-tests an attacker-chosen prime of up to 8,192 bits, then carries on the exchange as if it were the client. Published RFC 3526 primes are the worst case and cost the attacker nothing. The costly primality check arrived in 1.5.0; versions 1.2.0 to 1.4.22 accept the message without it.
CVE-2026-81535 (6.3). In builds made with --enable-fwd, DoChannelOpen() asked the forwarding policy callback about direct-tcpip channels but not forwarded-tcpip ones, and did not cap how many could be opened. A malicious peer could make the device allocate buffers for forwarding channels nobody authorized. A client also accepted forwarded-tcpip opens for ports it never asked the server to forward, which RFC 4254 section 7.2 forbids.
CVE-2026-83742 (5.3). wolfSSH_RealPath(), used to resolve SFTP paths, bounded each appended path component by the space left rather than the buffer size. Once the path passed half the buffer, a size calculation in wstrncat() wrapped round and the copy became unbounded. An authenticated SFTP user can send a path that writes one zero byte past a stack buffer and crashes the process. Applications that call wolfSSH_RealPath() directly with an output buffer smaller than the input face an unbounded copy. It affects 1.4.11 to 1.5.0 on non-Windows builds.
What to do
1. Find where wolfSSH runs
Search firmware source trees and build manifests for wolfssh, the wolfSSL/wolfssh repository and the Zephyr or ESP-IDF module of the same name. The FreeBSD ports tree also ships a security/wolfssh package. For devices you buy, ask the vendor which SSH stack and version the firmware uses.
2. Upgrade to 1.6.0
The release is tagged v1.6.0-stable on GitHub. Test before shipping: wolfSSL must now be built with --enable-wolfssh or compilation stops, RSA user authentication keys need 2,048 bits, strict key exchange (the Terrapin mitigation) is on by default, and the server drops a client after six failed logins, which wolfSSH_CTX_SetMaxAuthAttempts() changes.
3. If a firmware release is weeks away
- CVE-2026-16516: review the client's public key check callback. If it uses any of the three lax patterns above, pin the exact host key the device should accept and make sure no untrusted network sits between client and server until the fix ships.
- CVE-2026-83540: on Windows, stop wolfSSHd on any host where accounts with different privilege levels log in, or limit TCP 22 at the host firewall to administrators' machines.
- CVE-2026-84897: rebuild with
WOLFSSH_NO_DH_GEX_SHA256defined.WOLFSSH_NO_DHandNO_SHA256also imply it. - CVE-2026-81535: rebuild without
--enable-fwdif the product does not need port forwarding. - CVE-2026-83742: turn off SFTP where it is not used, or limit SFTP to trusted accounts.
4. Check for signs of abuse
For the Windows flaw, compare wolfSSHd's own log of who authenticated with the Windows Security log. Event ID 4624 (successful logon) records the account and the process that requested it; a 4624 from the wolfSSHd process for an account that did not authenticate in that window is the sign to look for. If you find one, treat the elevated account as compromised and reset its credentials.
For the other flaws, look for repeated SSH service crashes and watchdog resets on devices reachable from untrusted networks. If your client firmware logs the host key it receives, look for a server whose key type or curve suddenly changed.
Embedded SSH needs an owner
A library in firmware is patched only when someone ships new firmware. A software bill of materials per product (1.6.0 adds make sbom targets for CycloneDX and SPDX) turns a CVE like these into a list of affected products. Review how your SSH clients verify host keys too: trust on first use is common in embedded code, and it is what turns CVE-2026-16516 into impersonation.
Our red team code review covers how firmware calls libraries like wolfSSH, including host key callbacks and build flags, and safeguarding and hardening covers locking down exposed device services. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: wolfSSH ChangeLog (v1.6.0), NVD CVE-2026-16516, NVD CVE-2026-83540, NVD CVE-2026-84897, NVD CVE-2026-81535, NVD CVE-2026-83742, The Hacker Wire CVE-2026-16516, The Hacker Wire CVE-2026-83540, The Hacker Wire CVE-2026-83742, wolfSSH issue 1012, wolfSSH adds Zephyr support, Renesas wolfSSH partner page, Espressif wolfSSH component, wolfSSH 1.4.4 VxWorks support.