CVE-2026-94418 is a high severity (CVSS 7.5) certificate verification flaw in wolfSSL builds that define WOLFSSL_SMALL_CERT_VERIFY. A bad signature result can be hidden by a later parse error, which matters only if an application also overrides date errors. A fix was merged upstream in pull request 11500.
What's affected
The record names wolfSSL builds that define WOLFSSL_SMALL_CERT_VERIFY, a low memory option that is off by default and not enabled by platform presets. The weakness is CWE-347, improper verification of a cryptographic signature.
The record spells out the conditions. The build must define the option. The application must also install a verify callback with peer verification on that returns success for date errors, as wolfSSL's own test callback does under its override option. An application with no callback, or one that does not override date errors, still fails the handshake.
The fix is in wolfSSL pull request 11500, merged on September 21, 2026, which makes a failed signature take precedence over the later parse errors. I could not find a release number in the sources I read, so check wolfSSL's release notes for the version that includes it.
How to check if you're exposed
First check whether your build defines the option. Look in the generated options header of your installed build, or in the flags you pass to configure.
grep -rn "SMALL_CERT_VERIFY" /usr/local/include/wolfssl/options.h
The record lists the autotools routes that turn it on: the lowresource, leantls and tinytls13 settings with cert or mutualauth. Embedded builds may set it through a user settings header instead.
Then search your application for verify callbacks that accept date errors, meaning those that return success for before or after date failures. Both conditions have to be true for the issue to apply.
What to do now
- Update wolfSSL to a release that includes the fix from pull request 11500. Check the release notes for the first version that does.
- If you do not need the small cert verify option, rebuild without it.
- Remove any verify callback that returns success for date errors, or make sure it passes the original result through.
- Read the pull request's behavior notes before upgrading. It changes the session cache layout and makes a peer with no OCSP responder reach the CRL check, which can report a missing CRL where the handshake used to complete.
- Test certificate validation after the update, including expired and bad signature cases.
Why it matters
Certificate checks run in a fixed order, and some policies, such as letting a device with a wrong clock connect, depend on that order. The record explains that splitting the signature check out of the parse step changed the precedence, so the signature failure could be reported as a later error that the callback was already willing to ignore. CWE-347 issues are about whether a signature really gates trust.
The score is high but the preconditions are narrow: a non default build option plus a permissive callback. The record does not mark exploitation and the CVE is not in CISA's catalog. Embedded and IoT products are the likeliest to match both conditions.
Quick check
Is every wolfSSL user affected?
No. The record requires WOLFSSL_SMALL_CERT_VERIFY, which is off by default, and a callback that overrides date errors.
Is there a release version for the fix?
I could not confirm one. The fix was merged in pull request 11500, so check wolfSSL's release notes.
Sources
Last reviewed: 18 October 2026.
