CVE-2025-11625 is a critical severity improper host authentication flaw (CVSS 9.8) in wolfSSH clients, version 1.4.20 and earlier. It allows authentication bypass and can leak client credentials. The fix is in pull request 840, so upgrade to a release that includes it and confirm in the release notes.
What's affected
The record names wolfSSH clients at version 1.4.20 and earlier. The flaw is an improper host authentication problem, which means the client does not properly confirm that it is talking to the server it meant to reach. It is classed under CWE-287 (Improper Authentication).
This concerns the client side. A product that uses wolfSSH only as a server is not in the scope the record describes. A product that opens outbound SSH or SFTP connections with wolfSSH, such as a device that pushes logs or fetches updates, is.
The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: a network attack, low complexity, no privileges, and no user interaction.
The record links pull request 840, titled "improvements to keying and track side". The GitHub page shows that it was merged on 14 October 2025. It lists two commits, including one described as updating the key exchange init response after adding keying track sides. The pages I fetched do not name the release that contains the change.
How to check if you're exposed
Find every place that wolfSSH acts as a client. That includes your own code, embedded devices that connect outward, and third party products. Check the version of the library in each.
In a source tree, compare the version and look for the merged change:
git -C wolfssh describe --tags
git -C wolfssh log --oneline | grep -i "keying"
For products you do not build, check the vendor advisory for wolfSSH. Then look at what the client authenticates to. If it logs in to a server with a password or a key, the credentials are what a bypass could expose, so those are the secrets to consider rotating.
Generating an SBOM for each build gives you a direct answer to the question of where the library lives. gold.safeguard.sh/scan can scan a manifest in your browser.
What to do now
-
Inventory wolfSSH client use and record the version for each.
-
Move to a release that includes the change from pull request 840, after you confirm the exact version in the release notes. The pages I fetched did not state one.
-
Where you cannot update soon, limit outbound SSH from affected devices to known server addresses at the firewall.
-
Pin and verify server host keys wherever your product allows it.
-
Rotate credentials that an affected client used, if you cannot rule out an interception on an untrusted network.
-
Rebuild firmware that statically links the library, and ask device vendors for updated images.
Why it matters
Host authentication is the check that stops a client from handing credentials to an impostor. When it is incomplete, a person in the network path can pose as the server. That is CWE-287 (Improper Authentication) in the record's terms.
The risk grows on networks you do not control, such as public links, shared hosting, and field devices that connect over mobile networks. Credential leakage is the worst outcome, because those secrets often work elsewhere too.
The record does not mark the CVE as exploited in the CISA Known Exploited Vulnerabilities catalog, and the pages I fetched do not report exploitation.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect my SSH server?
The record describes clients at version 1.4.20 and earlier. A server only deployment is not the case it describes, though you should still keep the library current.
What should I rotate?
Any password or key that an affected client used to log in to a remote server, if you have reason to think the connection crossed a network you do not trust.
Sources
- CVE-2025-11625 on Safeguard Gold
- NVD record for CVE-2025-11625
- wolfSSH pull request 840, improvements to keying and track side
Last reviewed: 19 October 2026.
