CVE-2026-5194 is a certificate validation flaw (CWE-295) in wolfSSL: missing hash size and OID checks let signature verification accept digests smaller than allowed. NVD scores it 9.1 critical and wolfSSL rates it critical. Update to wolfSSL 5.9.1 or later and rebuild products that bundle the library.
What's affected
wolfSSL releases before 5.9.1. The project's changelog lists the fix in release 5.9.1 (8 April 2026), in pull request 10131, and marks it Critical.
The NVD description and the changelog differ in scope. NVD says the issue affects ECDSA and ECC verification when EdDSA or ML-DSA is also enabled. The changelog is wider: it says the missing checks affect several signature algorithms, including ECDSA and ECC, DSA, ML-DSA, ED25519 and ED448.
The changelog advises builds that have both ECC and EdDSA or ML-DSA enabled, and that verify certificates, to update to the latest release. The record adds that the risk is to ECDSA certificate based authentication if the public CA key used is also known, which is normal for public CAs.
How to check if you're exposed
Find the wolfSSL version your product links against. For a system package:
dpkg -l | grep -i wolfssl
rpm -q wolfssl
For a build from source, read the version macro in wolfssl/version.h. Embedded firmware often bundles wolfSSL as source, so ask the vendor or search the source tree:
grep -rn "LIBWOLFSSL_VERSION_STRING" .
Anything before 5.9.1 is affected, because the changelog lists the fix in that release. Then check your build options. If your build enables ECC together with EdDSA (ED25519 or ED448) or ML-DSA, and your product verifies certificates, it is in the group the changelog names. Configure options are recorded in config.log for builds made with autotools.
You can also run the free in-browser dependency scan or browse the Gold directory to see where this component shows up in your stack.
What to do now
- Inventory every product that embeds wolfSSL, in both source and binary form.
- Update to wolfSSL 5.9.1 or later and rebuild, retesting certificate validation paths.
- Prioritize products that verify certificates with ECC and also have EdDSA or ML-DSA enabled.
- Contact suppliers of devices with wolfSSL inside and ask for fixed firmware dates.
- Include certificate validation tests with undersized digests in your regression suite.
- Record the wolfSSL version in your software bill of materials so the next advisory is quick to answer.
Why it matters
A signature check should confirm two things: that the signature matches, and that the digest used is strong enough for the key type. The record says digest size and OID checks were missing, so a digest smaller than appropriate could be accepted. A smaller digest has fewer possible values, which reduces the work needed to produce a matching one.
The weakness is CWE-295, improper certificate validation. The impact is on authentication: the record says ECDSA certificate based authentication could be weakened if the public CA key is also known. Certificate verification is the root of trust for a TLS connection, so errors there matter more than their line count suggests.
The record does not report exploitation, and the CVE is not in the CISA KEV catalog. The record's reference list includes a note from Anthropic's research on the project, which is not a technical advisory, so rely on the wolfSSL changelog for the facts.
For teams that use wolfSSL inside devices, the challenge is the delivery chain. A fixed library in a repository does nothing for a gateway in a closet until its firmware is rebuilt and installed.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need EdDSA enabled to be affected?
NVD ties the issue to ECDSA with EdDSA or ML-DSA enabled. The changelog names more algorithms. Update regardless.
Is this an attack on TLS itself?
No. It is an implementation gap in one library's validation. Other libraries are not affected by this CVE.
Sources
Last reviewed: 19 October 2026.
