Vulnerability Disclosure: wolfSSH (CVE-2026-16516)

Date: October 6, 2026
Severity: Critical
Affected Users: Applications using the wolfSSH client with wolfSSH releases through v1.5.0 that rely on ECDSA host keys.
Fixed In: wolfSSH v1.6.0 (PR 1022, issue #1012)

Summary

A man-in-the-middle could substitute a server’s ECDSA host key with a key on a different curve and still pass signature verification, using a private key of the attacker’s own choosing. The attack requires a lax public key check callback in the client application.

Background

When an SSH client connects to a server, the two sides negotiate a host key algorithm. For ECDSA there are three: ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, and ecdsa-sha2-nistp521. Each name fixes both the signature algorithm and the curve. The server then sends its host key in the key exchange reply, and the client checks that the key is the one it expects and that the server’s signature over the exchange hash verifies with it.

Per RFC 5656 section 3.1, the ECDSA host key blob carries its own copy of this information: an algorithm name (for example ecdsa-sha2-nistp256), a curve identifier (for example nistp256) and the public point. A careful client treats those fields as claims to be checked against what was negotiated, not as instructions.

The Vulnerability

wolfSSH’s ParseECCPubKey() did not check them. It had two defects:

It chose the curve from the algorithm name inside the key blob, ignoring the algorithm that had actually been negotiated.
It skipped over the curve identifier string in the blob and discarded it without comparing it to anything.

So if ecdsa-sha2-nistp256 was negotiated, a man-in-the-middle could send a blob naming a different curve, such as nistp384, and wolfSSH would import the point on that curve. The attacker generates a key pair on that other curve, so the attacker holds the private key, signs the exchange hash with it, and the signature verifies against the key the client just imported. Signature verification proves only that the signer holds the private key for the key it was handed. It cannot tell the client that this is the wrong key.

The attack depends on the application’s public key check callback, set with wolfSSH_CTX_SetPublicKeyCheck(). That callback is where an application decides whether the host key is the one it trusts. If it compares the whole key against a known value, a substituted key fails there and the connection is refused. A callback that is lax, for example one that accepts any key on first use, or that checks only the algorithm name, lets the substituted key through. Without a lax callback, the attack does not succeed. The exposure is therefore limited to applications that do not pin the exact host key.

Recommendation

Update to wolfSSH v1.6.0 or later.

If you cannot update immediately, make sure your public key check callback compares the complete host key against a known value, such as a stored fingerprint of the exact key, and does not accept keys on algorithm name alone.

Credit

Thank you to zhangph (GitHub afldl) for reporting this issue.

References

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now