wolfSSL has pushed out version 1.6.0 of wolfSSH to resolve five security vulnerabilities, including a high-stakes host key verification bypass that could enable man-in-the-middle impersonation of SSH servers. The updates patch issues ranging from critical to medium severity, affecting various builds prior to the 1.6.0 release.
What Vulnerabilities Were Fixed?
The most severe, CVE-2026-16516, stems from the SSH key exchange process. The client was not enforcing that the ECDSA host key’s curve matched the negotiated algorithm, allowing an attacker to swap in a key using a different curve. If the attacker owns the private key and the application includes a weak public-key check callback, the signature would still validate. Not every client build is exposed—exploitation requires specific callback handling. Builds up to 1.5.0 are affected.
A high‐severity flaw, CVE-2026-83540, affects wolfSSHd on Windows versions 1.4.15 through 1.5.0. It allowed shared Windows logon tokens to be misused across concurrent connections, meaning one authenticated user could potentially gain the system identity of another—even one with greater privileges.
The medium‐severity issues fill in the rest:
• CVE-2026-84897 relates to mishandling of Diffie-Hellman group exchange. A server would accept messages meant only for server-side use, letting an unauthenticated client force CPU-intensive prime number validation or trigger unexpected client-side processing.
• CVE-2026-81535 allows forwarded TCP/IP channels without policy checks; clients might accept remote-forward channels they never asked for.
• CVE-2026-83742 arises from a miscalculation in path length within the wolfSSH_RealPath() function on non-Windows platforms. Crafted SFTP paths can corrupt memory or lead to crashes via buffer overruns.
Enhanced Defaults & Mitigations
wolfSSH 1.6.0 turns on stricter safeguards by default. It enables strict key exchange to shield users against “Terrapin-style” attacks, mandates RSA user authentication keys to be at least 2048 bits, and limits failed authentication attempts to six per session. These changes significantly bolster security hygiene for typical deployments.
Organizations using wolfSSH in mission-critical systems—particularly those running versions 1.5.0 or earlier—should prioritize upgrading to 1.6.0 immediately. Developers are encouraged to review their implementations for weak public key validation callbacks, unauthorized forwarding policies, and unsafe path validations.
These flaws underscore a wider pattern: even mature SSH libraries can conceal invasive issues tied to default settings and subtle protocol assumptions. wolfSSH is used widely in embedded, networking, and constrained-device environments, where differing build flags or platform constraints often leave outdated or misconfigured code in production. With this release, wolfSSH makes strides toward more secure defaults, but the onus remains on devs and deployers to audit critical settings.
