AI analysis
wolfSSH does not verify that the ECDSA curve identifier in a KEXDH_REPLY host-key blob matches the algorithm negotiated during key exchange. In ParseECCPubKey() the blob algorithm string is turned into a curve via NameToId and wcPrimeForId without comparison to ssh->handshake->pubKeyId, and the RFC 5656 curve identifier is discarded with GetSkip(). An active network man-in-the-middle can substitute a host-key blob on a different ECDSA curve for which the attacker holds the private key, so signature verification succeeds and the client accepts the wrong host key. This affects wolfSSH clients whose public-key callback is lax, such as trust-on-first-use, an algorithm-name-only check, or a fingerprint of the already-parsed key; the advisory does not name versions. No public proof of concept is known and the issue is not in CISA KEV.
What to do: Apply the wolfSSL-published wolfSSH fix as soon as it is available for your build, and until then require a strict host-key check that binds the accepted key to the negotiated algorithm and curve rather than trusting the parsed blob alone. Do not rely on trust-on-first-use, algorithm-name-only callbacks, or fingerprints computed from the already-parsed key. Prefer a pinned known host key and treat any unexpected ECDSA curve change as a failed authentication.
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
wolfSSH does not validate that the ECDSA curve identifier in a KEXDH_REPLY 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).