wolfSSL 5.9.4 Patches 11 TLS Vulnerabilities, Boosts Post-Quantum Crypto
Key Takeaways wolfSSL has released version 5.9.4, addressing 11 security vulnerabilities in its embedded TLS and cryptography library. The update fixes three high-severity, four medium-severity, and...
Key Takeaways
- wolfSSL has released version 5.9.4, addressing 11 security vulnerabilities in its embedded TLS and cryptography library.
- The update fixes three high-severity, four medium-severity, and four low-severity CVEs, primarily affecting specific build options and non-default configurations.
- Organizations utilizing wolfSSL in IoT, embedded systems, and other TLS/DTLS-dependent applications should prioritize upgrading.
- The new version also significantly enhances post-quantum cryptography capabilities, adding native Falcon support and FrodoKEM.
wolfSSL 5.9.4 Bolsters Security and Post-Quantum Capabilities
wolfSSL, a prominent provider of embedded TLS and cryptography libraries, has rolled out version 5.9.4, delivering critical security patches for 11 vulnerabilities. This update also introduces substantial advancements in post-quantum cryptography, positioning the library for future-proof security.
Table Of Content
The release is particularly vital for developers integrating wolfSSL into a diverse range of products, including IoT devices, embedded systems, servers, gateways, and any application relying on TLS or DTLS for secure communication channels.
The security fixes address a spectrum of flaws: three rated as high-severity, four as medium-severity, and four as low-severity. wolfSSL clarified that most of these vulnerabilities are tied to specific build options, API usage, or non-default configurations, rather than impacting every deployment universally.
Nonetheless, it is strongly recommended that organizations thoroughly review their compilation flags and update any affected installations. Particular attention should be paid to deployments configured for OpenSSL compatibility, those using Raw Public Keys, OCSP stapling, certificate revocation checks, or TLS 1.2 session resumption.
High-Severity TLS Vulnerabilities Addressed
Three high-severity flaws, if exploited, could compromise TLS peer authentication in certain configurations.
- CVE-2026-93302: This vulnerability impacts deployments that utilize trusted peer certificates via the
WOLFSSL_TRUST_PEER_CERToption. An attacker, knowing the target’s trusted CA certificates, could potentially forge a certificate authority clone and bypass validation. This issue might affect compatibility-focused setups used with software like nginx, HAProxy, stunnel, Apache HTTP Server, BIND, and rsyslog. - CVE-2026-89102: Clients with RFC 6961 multiple OCSP response stapling enabled are susceptible to this flaw. A vulnerable client could erroneously accept a certificate within a server-provided chain as a legitimate certificate authority without verifying its authorization to issue certificates. This could enable an attacker, possessing a certificate chaining to a trusted CA, to forge certificates for arbitrary identities.
- CVE-2026-89136: This third high-severity issue affects clients compiled with Raw Public Key support. A malicious server could transmit an unsolicited Raw Public Key, thereby circumventing the standard X.509 certificate-chain validation process. While Raw Public Key support is disabled by default, it can be activated through options such as
--enable-rpk,--enable-all, and--enable-distro.
Additional Security Patches and Enhancements
Beyond the critical fixes, wolfSSL 5.9.4 also fixes several certificate name-constraint validation errors. One medium-severity flaw (CVE-2026-89133) could allow a certificate to bypass DNS name constraints if an unconstrained CA was present between a name-constrained intermediate CA and the leaf certificate. Another issue (CVE-2026-89134) involved certificates with a Subject Alternative Name of a type other than DNS, which could permit an invalid Common Name to bypass a DNS name-constraint check.
Further fixes include addressing an out-of-order ChangeCipherSpec message in TLS 1.2 and DTLS 1.2 (CVE-2026-93304), an OCSP and CRL fallback issue that could result in the acceptance of a revoked certificate (CVE-2026-94417), and a session-cache reference problem impacting legacy TLS 1.2 and DTLS 1.2 resumption flows (CVE-2026-94419). The update also resolves a potential use-after-free condition during TLS shutdown (CVE-2026-15442).
| 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 note that simply updating the shared library may not be sufficient for all long-running applications. wolfSSL advises that for some affected applications, the WOLFSSL_CTX or the entire process should be restarted to ensure that persistent certificate or session states in memory are cleared and the fixes fully applied.
Expanded Post-Quantum Cryptography Support
Beyond security, wolfSSL 5.9.4 significantly advances its post-quantum cryptography (PQC) capabilities. The update now includes native Falcon signature support, removing its previous reliance on the liboqs library. It also introduces FrodoKEM, a new post-quantum key encapsulation mechanism, complete with optimized implementations for x86_64, AArch64, AArch32, and Thumb2 platforms.
The release integrates SLH-DSA authentication for TLS 1.3 and DTLS 1.3 handshakes across all 12 parameter sets. Developers can now also configure post-quantum-only TLS 1.3 setups, leveraging ML-KEM key exchange with ML-DSA or SLH-DSA authentication, entirely bypassing traditional cryptographic algorithms like RSA, elliptic-curve cryptography, or Diffie-Hellman.
Further PQC enhancements include AVX512 acceleration for ML-KEM and ML-DSA, ML-DSA support for PKCS#7 and CMS SignedData, and a convenient --enable-all-quantum-crypto configuration bundle. These improvements are crucial for organizations preparing their systems against the looming threat of cryptographically relevant quantum computers.
What You Should Do
- Upgrade Immediately: All organizations running wolfSSL versions 5.9.2 or earlier must identify their enabled build features and upgrade to version 5.9.4 or a downstream package containing these fixes.
- Prioritize Critical Systems: Give immediate priority to systems utilizing trusted-peer certificate APIs, multi-OCSP stapling, Raw Public Keys, OpenSSL compatibility APIs, OCSP plus CRL checking, and legacy session resumption.
- Restart Applications: For long-running applications, do not assume a shared library update is enough. Restart the
WOLFSSL_CTXor the entire application process to ensure all certificate and session states are cleared and the patches are fully active. - Review Build Configurations: Scrutinize your wolfSSL compilation flags and configurations to understand which specific vulnerabilities might affect your deployments.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.