CVE-2026-16516: wolfSSH ECDSA host key curve not validated against negotiated algorithm
wolfSSH does not validate that the ECDSA curve identifier in a KEXDHREPLY host key blob matches the algorithm negotiated during key exchange. In ParseECCPubKey() (src/internal.c), the blob's algorithm string is used to derive the curve via NameToId/wcPrimeForId without checking against the negotiated ssh->handshake->pubKeyId, and the RFC 5656 curve identifier string is discarded via GetSkip() rather than compared. An active network man-in-the-middle attacker can substitute a host key blob containing a different ECDSA curve, causing the client to import the key on the wrong curve. Because the attacker controls the private key for the substituted curve, signature verification passes. Exploitation requires an active MitM position and a lax public key check callback (e.g., TOFU, algorithm-name-only check, or fingerprint match against the parsed key).
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to exploitation?
wolfSSH clients that use ECDSA host keys and can be reached by an active network man-in-the-middle are exposed when their public-key verification callback is lax. Examples include trust-on-first-use, checks limited to the algorithm name, or fingerprint checks performed against the parsed substituted key.
What does an attacker need to exploit this issue?
The attacker needs an active MitM position during SSH key exchange and a private key for the different ECDSA curve they substitute in the host-key blob. No authentication or user interaction is required by the listed CVSS vector.
Are strict host-key verification deployments affected in the same way?
The described exploitation depends on a lax public-key check callback. A callback that reliably validates the expected host key rather than trusting the parsed substituted key does not meet the stated exploitation condition.
What can be done if updating wolfSSH is not immediately possible?
Avoid lax public-key validation callbacks and enforce verification of the expected host key. In particular, do not rely solely on TOFU, algorithm-name-only checks, or fingerprints derived from the newly parsed host key.