wolfSSL 5.9.4 Fixes 11 TLS Security Flaws and Expands Post-Quantum Cryptography Support

wolfSSL has released version 5.9.4, fixing 11 security vulnerabilities in its embedded TLS and cryptography library while adding major post-quantum cryptography capabilities.

The update is important for developers using wolfSSL in IoT devices, embedded products, servers, gateways, and applications that depend on TLS or DTLS for secure communications.

The release addresses three high-severity, four medium-severity, and four low-severity CVEs. wolfSSL said most flaws affect particular build options, APIs, or non-default configurations rather than every deployment.

Still, organizations should review their compilation flags and update affected installations, especially deployments using OpenSSL-compatible settings, Raw Public Keys, OCSP stapling, certificate revocation checks, or TLS 1.2 session resumption.

The three high-severity flaws could weaken TLS peer authentication in certain builds. CVE-2026-93302 affects deployments using trusted peer certificates through WOLFSSL_TRUST_PEER_CERT.

The issue could allow a forged certificate authority clone to pass validation when an attacker knows the CA certificates trusted by the target. It may affect compatibility-focused configurations used with software such as nginx, HAProxy, stunnel, Apache HTTP Server, BIND, and rsyslog.

wolfSSL 5.9.4 Fixes TLS Security Flaws

CVE-2026-89102 affects clients that enable RFC 6961 multiple OCSP response stapling. A vulnerable client could accept a certificate in a server-provided chain as a certificate authority without checking whether that certificate is authorized to issue certificates. An attacker with a certificate chaining to a trusted CA could potentially forge certificates for arbitrary identities.

The third high-severity issue, CVE-2026-89136, affects clients built with Raw Public Key support. A malicious server could send an unsolicited Raw Public Key and bypass normal X.509 certificate-chain validation.

Raw Public Key support is turned off by default. However, it is enabled through options such as –enable-rpk, –enable-all, and –enable-distro.

wolfSSL 5.9.4 also fixes certificate name-constraint validation errors. One medium-severity flaw could allow a certificate to escape DNS name constraints if an unconstrained CA appeared between a name-constrained intermediate CA and the leaf certificate.

Another issue involved certificates that carried a Subject Alternative Name of a type other than DNS, allowing an invalid Common Name to bypass a DNS name-constraint check.

Other fixes address an out-of-order ChangeCipherSpec message in TLS 1.2 and DTLS 1.2, an OCSP and CRL fallback issue that could accept a revoked certificate, and a session-cache reference issue affecting legacy TLS 1.2 and DTLS 1.2 resumption flows. The release also resolves a potential use-after-free condition during TLS shutdown.

Administrators should not assume that only updating the shared library is enough. For some affected long-running applications, wolfSSL states that the WOLFSSL_CTX or entire process should be restarted because certificate or session state may persist in memory.

Beyond security fixes, wolfSSL 5.9.4 significantly expands its post-quantum cryptography support. The release adds native Falcon signature support, replacing the prior dependency on the liboqs library.

It also introduces FrodoKEM, a post-quantum key encapsulation mechanism, with optimized implementations for x86_64, AArch64, AArch32, and Thumb2 platforms.

The update adds SLH-DSA authentication for TLS 1.3 and DTLS 1.3 handshakes across all 12 parameter sets. Developers can also build post-quantum-only TLS 1.3 configurations using ML-KEM key exchange with ML-DSA or SLH-DSA authentication, without traditional RSA, elliptic-curve cryptography, or Diffie-Hellman algorithms.

wolfSSL also added AVX512 acceleration for ML-KEM and ML-DSA, ML-DSA support for PKCS#7 and CMS SignedData, and an –enable-all-quantum-crypto configuration bundle.

These improvements position the library for organizations preparing systems against future cryptographically relevant quantum computers.

Organizations running wolfSSL 5.9.2 or earlier should identify enabled build features and upgrade to version 5.9.4 or a downstream package containing the fixes.

Priority should be given to systems using trusted-peer certificate APIs, multi-OCSP stapling, Raw Public Keys, OpenSSL compatibility APIs, OCSP plus CRL checking, and legacy session resumption.

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

The post wolfSSL 5.9.4 Fixes 11 TLS Security Flaws and Expands Post-Quantum Cryptography Support appeared first on Cyber Security News.