Cert signature bypass in wolfSSL small-cert builds
CVSS 4.0
2.3low
EPSS
—
Published
()
Modified
AI analysis
In wolfSSL builds compiled with WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse() runs the peer-certificate signature check separately from parsing to limit peak memory, then merges the signature result back only when parsing returned success, so any parse error hides ASN_SIG_CONFIRM_E. Validity-date, name-constraint, and critical-extension checks normally run only after ConfirmSignature() succeeds, so splitting the check inverts that order and lets a date failure conceal a bad signature. An on-path attacker needs no real CA key: a certificate with the expected subject, the trusted CA named as issuer, arbitrary signature bytes, a past validity window, and the attacker's own key is enough, but only if the application also installs a WOLFSSL_VERIFY_PEER callback that returns success for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E. TLS 1.2, TLS 1.3, and DTLS are affected in both directions; a consented chain certificate can be cached in the WOLFSSL_CTX certificate manager until the context or process is restarted, while builds with no callback, or a callback that returns the preverify result for date errors, still fail the handshake. No public proof of concept is known, it is not on the CISA KEV list, and CVSS 4.0 rates it 2.3 (low).
What to do: Rebuild without WOLFSSL_SMALL_CERT_VERIFY unless a low-resource configuration truly requires it, and do not return success from a WOLFSSL_VERIFY_PEER callback for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E. Apply the vendor fix once wolfSSL confirms it for this CVE (a related report ties multiple TLS fixes to 5.9.4; verify this issue is included). If a forged chain certificate may already have been accepted, restart the WOLFSSL_CTX or the process so it is not reused from the certificate-manager cache.
Affected
wolfSSL
Builds compiled with WOLFSSL_SMALL_CERT_VERIFY (off by default; not set by CMake, --enable-all, or --enable-distro). Reachable via autotools --enable-lowresourc
Estimated exposure
nicheNo basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
Under WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse() runs the certificate signature check separately from the parse to keep peak memory down, then merges the two results, but it merged the signature result back only when the parse returned 0, so any parse error hid it. ParseCertRelative() reaches its validity-date, name-constraint and critical-extension checks only after ConfirmSignature() has passed, so splitting the signature check out inverts the precedence that makes "override date errors" a sound policy, and ASN_SIG_CONFIRM_E is never surfaced anywhere. The attacker needs no key material from the real PKI and no CA compromise: a self-made certificate carrying the expected subject name, the trusted CA's subject as its issuer, arbitrary bytes where the signature goes, a validity window in the past and the attacker's own key pair is sufficient. Affected builds define WOLFSSL_SMALL_CERT_VERIFY, which is off by default, is not set implicitly by any platform or preset header, and is not reachable from any CMake option; the autotools routes are --enable-lowresource, --enable-leantls, --enable-tinytls13=cert and --enable-tinytls13=mutualauth, and examples/configs/user_settings_embedded.h reaches it through WC_CFG_SMALL_CERT_VERIFY, which ships as 0, while neither --enable-all nor --enable-distro enables it at all. The application must additionally install a verify callback through wolfSSL_CTX_set_verify() or wolfSSL_set_verify() with WOLFSSL_VERIFY_PEER that returns 1 for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E; wolfSSL ships this exact shape as myVerify() in wolfssl/test.h under VERIFY_OVERRIDE_DATE_ERR, which examples/client -D selects. An application with no callback, or whose callback returns preverify for date errors, still fails the handshake, and wolfSSL_CertManagerVerifyBuffer() and wc_CheckCertSignature() report ASN_SIG_CONFIRM_E correctly in the same binary. TLS 1.2 and TLS 1.3 are affected in both directions, and DTLS reaches the same function; where the forged certificate is a chain certificate the callback's consent causes it to be cached in the WOLFSSL_CTX certificate manager, so an exposed deployment must restart the context or the process rather than merely reconnect.
wolfSSL 5.9.4 fixes 11 TLS and certificate-validation flaws, including trusted-peer and OCSP authentication bypasses.
wolfSSL 5.9.4 fixes 11 flaws in TLS and DTLS handshakes, X.509 validation, OCSP stapling, session resumption, and memory safety. CVE-2026-93302, affecting 5.3.0 through 5.9.2, can let a forged CA clone pass trusted-peer checks when WOLFSSL_TRUST_PEER_CERT is enabled. High-severity CVE-2026-89102 and CVE-2026-89136 may bypass authentication in multi-OCSP and Raw Public Key builds. Other fixes include ChangeCipherSpec ordering, NameConstraints bypasses, skipped CRL checks, session-cache poisoning, and a heap use-after-free. No exploitation is reported.
wolfSSL 5.9.4 patches 11 TLS vulnerabilities, including three high-severity certificate validation bypasses, and adds post-quantum cryptography features.
wolfSSL 5.9.4 fixes 11 CVEs (three high, four medium, four low) in its embedded TLS/cryptography library, most affecting specific build options rather than default configurations. High-severity issues include CVE-2026-93302 (trusted-peer certificate bypass via forged CA clone), CVE-2026-89102 (OCSP stapling certificate forgery), and CVE-2026-89136 (Raw Public Key authentication bypass), affecting versions from 3.15.5 through 5.9.2. The release also expands post-quantum support with native Falcon signatures, FrodoKEM, SLH-DSA for TLS 1.3, and PQ-only ML-KEM/ML-DSA configurations. wolfSSL warns that long-running applications may need full process restarts because certificate or session state can persist in memory.