wolfSSL 5.9.4 Fixes 11 TLS Security Flaws and Expands Post-Quantum Cryptography Support
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.
- Three high-severity flaws weaken TLS peer authentication in certain builds
- Affected configurations include trusted-peer certs, multi-OCSP stapling, and Raw Public Keys
- Compat-focused builds with nginx, HAProxy, stunnel, Apache, BIND, rsyslog may be affected
- Post-quantum additions: native Falcon, FrodoKEM, SLH-DSA, PQ-only TLS 1.3
- Restart long-running processes after patching; stale certificate/session state can persist
Vulnerabilities mentionedAll →
- CVE-2026-891028.3—Certificate forgery via OCSP multi-stapling in wolfSSLpublished · wolfSSL+10 related
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-89102 |
Full article736 words · extracted from cybersecuritynews.com · click to collapse
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.
| CVE | Severity | Affected Versions | Vulnerability | Fixed In |
|---|---|---|---|---|
| CVE-2026-93302 | High | 5.3.0–5.9.2 | Trusted-peer certificate bypass | 5.9.4 |
| CVE-2026-89102 | High | 5.7.2–5.9.2 | OCSP stapling certificate forgery | 5.9.4 |
| CVE-2026-89136 | High | 5.6.0–5.9.2 | Raw Public Key auth bypass | 5.9.4 |
| CVE-2026-93304 | Medium | 4.7.0–5.9.2 | ChangeCipherSpec bypass | 5.9.4 |
| CVE-2026-89133 | Medium | ≤5.9.2 | X.509 NameConstraints bypass | 5.9.4 |
| CVE-2026-89134 | Medium | 5.9.2 | Common Name constraint bypass | 5.9.4 |
| CVE-2026-89135 | Medium | 5.8.4–5.9.2 | Unverified CA persistence | 5.9.4 |
| CVE-2026-15442 | Low | 4.4.0–5.9.2 | TLS shutdown use-after-free | 5.9.4 |
| CVE-2026-94417 | Low | ≤5.9.2 | OCSP/CRL check bypass | 5.9.4 |
| CVE-2026-94418 | Low | 3.15.5–5.9.2 | Certificate signature bypass | 5.9.4 |
| CVE-2026-94419 | Low | 5.3.0–5.9.2 | TLS session-cache confusion | 5.9.4 |
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
Abinayahttps://cybersecuritynews.com/
Abi is a Security Editor and fellow reporter with Cyber Security News. She is covering various cyber security incidents happening in the Cyber Space.