CVE-2025-14942 is a critical flaw (CVSS 9.8) in wolfSSH 1.4.21 and earlier. A manipulated key exchange can leak a client's password in the clear, trick it into sending a bogus signature or make it skip user authentication. Update wolfSSH or apply the fix patch, and rotate credentials the library used.
What's affected
Per the CVE record, wolfSSH client applications on version 1.4.21 and earlier are affected. The advisory text also recommends the fix for wolfSSH server applications. It says no specific attack on servers is known, but the same defect is present there.
The fix landed upstream in wolfSSL/wolfssh pull request 855, titled "Out Of Order Messaging Checking", merged on 15 December 2025. The pull request describes tighter checks on which SSH messages are allowed at each state of the handshake, for both client and server, with a regression test for specific failure cases.
The record does not name a fixed release number, and I could not confirm one from the pages fetched. Check the wolfSSH release notes and wolfSSL's advisory for the first release that contains pull request 855.
How to check if you're exposed
wolfSSH is a library, so it is compiled into other software. Finding it takes a few steps.
- Search your source trees and vendor directories for
wolfsshand check the version macro inwolfssh/version.h. - Check dependency manifests and build files in firmware and embedded projects, where wolfSSH is common. Look in CMake files, Makefiles, Zephyr west manifests and vendored copies.
- Ask suppliers of devices and appliances whether their SSH client or server uses wolfSSH, and which version.
A software bill of materials makes step 3 much faster if you have them.
What to do now
- Find every product you build or run that bundles wolfSSH, client or server.
- Update to a wolfSSH release that includes pull request 855, or apply the patch from that pull request. Confirm the release number in wolfSSL's notes.
- Rotate passwords and keys used by any wolfSSH client at or below 1.4.21. The advisory recommends updating credentials.
- Prefer public key authentication over passwords for automated clients while you work through the fixes.
- Ask embedded and device vendors for a firmware update that carries the fixed library.
Why it matters
The weakness is CWE-287, Improper Authentication. The SSH handshake is a state machine: each side expects certain messages at certain times. If an implementation accepts messages out of order, a hostile peer can steer the other side into a state the designers never intended. Here that means a client can be led to reveal a password or to skip authentication altogether.
The vector is network based with no privileges and no user interaction, which is why the score is 9.8. The record does not list this CVE in CISA's Known Exploited Vulnerabilities catalog, and the advisory says nothing about active attacks. Even so, a client that talks to an untrusted or compromised server is exactly where this class of bug bites, so devices that connect out over SSH deserve priority.
Finding libraries that hide inside other software
Embedded libraries are the hard part of this one. The free in-browser dependency scan at https://gold.safeguard.sh/scan checks a manifest against known vulnerabilities without installing anything. The Gold directory pages for each CVE and CWE collect the same facts in one place. For compiled code, an SBOM from your supplier is the cleaner answer.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is this only a client problem?
The advisory focuses on clients, but it recommends the fix for servers too because the same defect is present. It says no specific server attack is known.
Why rotate credentials after patching?
The flaw can leak a password in the clear. Patching stops future leaks but does not undo past ones, so the advisory recommends updating credentials.
Sources
Last reviewed: 19 October 2026.
