wolfSSL 5.9.4 Patches 11 Security Flaws Affecting TLS and Certificate Validation

wolfSSL has released version 5.9.4, which addresses 11 security vulnerabilities related to TLS and DTLS handshakes, X.509 certificate validation, certificate revocation, OCSP stapling, session resumption, and memory safety.

This release is particularly important for deployments utilizing OpenSSL-compatible settings, optional certificate validation features, or persistent, long-running TLS contexts.

The most critical issue, tracked as CVE-2026-93302, affects how wolfSSL handles trusted-peer certificates. This vulnerability occurs when builds enable WOLFSSL_TRUST_PEER_CERT and load CA certificates using either wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert().

The flawed verification logic fails to properly consider the public key, allowing a forged CA clone to pass trust verification as long as the attacker knows which CA certificates the target accepts.

This issue poses additional risks in builds that define OPENSSL_COMPATIBLE_DEFAULTS, as the vulnerable trusted-peer behavior can extend to broader CA-loading paths. wolfSSL indicates that the affected certificate verification path applies to versions 5.3.0 through 5.9.2.

The vendor recommends upgrading, applying the patch, or disabling OpenSSL-compatible defaults and avoiding the affected trust-peer APIs.

wolfSSL 5.9.4

Two additional high-severity flaws may allow certificate authentication bypasses in certain configurations.

CVE-2026-89102 affects clients that use RFC 6961 multiple OCSP stapling via wolfSSL_UseOCSPStaplingV2() with WOLFSSL_CSR2_OCSP_MULTI.

A wolfSSL client could incorrectly treat any peer-chain certificate as a certificate authority without validating its authorization. An attacker possessing any certificate trusted by the client, along with its private key, could potentially forge certificates for arbitrary identities.

This risk is heightened because the untrusted end-entity certificate can be stored in a persistent trust store, impacting subsequent TLS connections that reuse the same context.

CVE-2026-89136 impacts builds with Raw Public Key support enabled via –enable-rpk, –enable-all, or –enable-distro. A TLS 1.2, TLS 1.3, or DTLS 1.2 client could accept an unsolicited server_cert_type=RawPublicKey value, enabling a malicious or misconfigured server to bypass authentication. Notably, Raw Public Key support is disabled by default, limiting exposure for standard builds.

wolfSSL 5.9.4 also fixes CVE-2026-93304, a medium-severity issue related to TLS and DTLS 1.2 handshakes that involves an out-of-order ChangeCipherSpec message.

An attacker could send ChangeCipherSpec before the client transmits ClientKeyExchange, which may cause the client to install deterministic read keys before a master secret has been established.

In certain scenarios, this could allow an attacker to complete a handshake while impersonating the server and deliver data the client accepts as authentic.

TLS clients are vulnerable when applications use wolfSSL_inject() or enable read-ahead, while DTLS clients may be at risk when datagrams deliver records independently. PSK configurations face increased risk, as a fake server may succeed without knowing the PSK.

The update further addresses two NameConstraints validation flaws:

• CVE-2026-89133 allowed certificate chains with an unconstrained intermediate CA to reset NameConstraints validation state, potentially permitting certificates for unauthorized hostnames.
• CVE-2026-89134 involved certificates containing a non-DNS Subject Alternative Name, where an out-of-scope Common Name could bypass DNS NameConstraints checks.

These defects are particularly significant in enterprise PKI environments that utilize NameConstraints to limit the domains subordinate CAs can issue certificates for.

Other fixes include CVE-2026-94417, which could result in skipped Certificate Revocation List (CRL) checks when both OCSP and CRL validation are enabled, but a certificate lacks an OCSP responder URL. As a result, it could accept a revoked certificate.

In long-running processes affected by this issue, an unchecked intermediate certificate may remain trusted in the certificate manager, so administrators are advised to rebuild or restart the affected WOLFSSL_CTX instances after upgrading.

wolfSSL has also addressed CVE-2026-94418, a low-severity vulnerability related to certificate signature validation bypass in low-memory builds using WOLFSSL_SMALL_CERT_VERIFY and date-error override callbacks.

CVE-2026-94419 fixes a session cache poisoning issue in legacy wolfSSL_get_session() and wolfSSL_set_session() flows, where a server-controlled TLS 1.2 session ID could overwrite a process-wide cache entry.

Finally, CVE-2026-15442 resolves a potential heap use-after-free issue during TLS shutdown following a partial wolfSSL_read().

In addition to these security fixes, wolfSSL 5.9.4 introduces several new features, including Argon2 password hashing, native Falcon post-quantum signatures, FrodoKEM, SLH-DSA support for TLS 1.3 and DTLS 1.3, AES-GCM-SIV, KMAC, cSHAKE, and software bill of materials generation through SPDX, CycloneDX, and OmniBOR targets.

Organizations should prioritize upgrading wherever they use wolfSSL in TLS clients, embedded devices, and other deployment scenarios.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC