CVE-2026-16516 is a high severity (CVSS 7.4) flaw in the wolfSSH client. It accepts an ECDSA host key blob whose curve differs from the negotiated algorithm, which lets an active man-in-the-middle substitute a key. The upstream fix is a commit that binds the curve to the negotiated algorithm.
What's affected
wolfSSH, the SSH library from wolfSSL, in the client key exchange path. The record says that in ParseECCPubKey() in src/internal.c, the algorithm string in the KEXDH_REPLY host key blob is used to pick the curve, without checking it against the negotiated algorithm. The RFC 5656 curve identifier string is skipped instead of compared.
The record gives no version range. The upstream fix is commit 31d1369, titled "Bind ECDSA host key curve to negotiated algo", which makes the code derive the curve from the negotiated algorithm and compare both the algorithm name and curve name in the blob. The GitHub issue is number 1012. I could not confirm which tagged release first contains the fix, so check the wolfSSH release notes for the first release after that commit.
How to check if you're exposed
Find out whether your software bundles wolfSSH and whether it acts as an SSH client. Search your build and dependency manifests:
grep -ril wolfssh .
If you vendor the source, look at ParseECCPubKey in src/internal.c. If it does not compare the blob's algorithm and curve names to the negotiated algorithm, you are missing the fix.
Then review your host key verification callback. The record says exploitation needs a lax public key check, such as trust on first use, a check on the algorithm name only, or a fingerprint match against the parsed key.
What to do now
- Identify products and firmware in your estate that embed wolfSSH as an SSH client.
- Update to a wolfSSH release that includes commit 31d1369, after confirming the release in the project notes.
- If you cannot update yet, make the host key callback compare the full expected key from a pinned source rather than only the algorithm name or a fingerprint of the parsed key.
- Avoid trust on first use over untrusted networks for devices that run this client.
- Ask vendors of embedded devices whether their firmware includes the fix.
Why it matters
CWE-345 is insufficient verification of data authenticity. Here, the client trusts a field inside the server's key blob to choose which elliptic curve to use. An attacker in the path can swap in a key on another curve and, since they hold the matching private key, signatures verify. The handshake then looks valid to code that does not pin the exact key.
The attack complexity is rated high because it needs an active network position plus a weak callback. That makes the application's own key pinning the deciding control. The fix removes the library behavior, but strict host key checks are worth keeping anyway.
The weakness class here is CWE-345 (Insufficient Verification of Data Authenticity). The NVD record scores it 7.4, which is high severity. The CVSS vector reads attack vector over the network, high attack complexity, no privileges required, no user interaction. Scope is unchanged. Impact on confidentiality, integrity and availability is rated high, high and none. The record's KEV flag is false, so this CVE is not in CISA's Known Exploited Vulnerabilities catalog, and the advisory I fetched does not report exploitation.
Try it yourself
A free in-browser dependency scan at gold.safeguard.sh/scan shows which of your components match known CVEs. The demo below walks through the idea.
Click through it at your own pace, or open it full screen.
Quick check
Is a strict host key check enough on its own?
The record says exploitation needs a lax check, so comparing the complete expected key helps a lot. Still, update the library so the curve is bound to the negotiated algorithm.
Sources
- wolfSSH issue 1012
- wolfSSH commit 31d1369
- Safeguard Gold entry for CVE-2026-16516, which summarizes the NVD record
Last reviewed: 18 October 2026.
