wolfSSL has rolled out version 5.9.4, which fixes 11 security vulnerabilities ranging from low to high severity, and introduces enhanced post-quantum cryptography support. The new release is especially relevant for developers working with embedded devices, IoT, servers, gateways, and applications that utilize TLS or DTLS for secure communications. Many of the flaws only affect non-default settings, specific APIs, or particular build configurations. However, systems using OpenSSL compatibility, Raw Public Keys, OCSP stapling, certificate revocation checking, or TLS 1.2 session resumption are among the more exposed.
Major Security Fixes in 5.9.4
The update addresses three high-severity CVEs, four medium, and four low-severity ones. A major high-severity issue (CVE-2026-93302) involves deployments that rely on trusted peer certificates through the WOLFSSL_TRUST_PEER_CERT setting. Attackers who know which CA certificates are trusted could misuse this to bypass certificate authority validation—especially in setups compatible with nginx, HAProxy, stunnel, Apache HTTP Server, BIND, or rsyslog.
Another critical problem (CVE-2026-89102) concerns clients allowing multiple OCSP responses (RFC 6961 stapling). In this flaw, a server-provided certificate chain might include an unauthorized cert acting like a CA—leading to arbitrary certificate forgeries. A third high-severity CVE (CVE-2026-89136) deals with Raw Public Key (RPK) support: a malicious server could send an unsolicited RPK, sidestepping standard X.509 certificate chain validation. RPK support isn’t enabled by default but is activated with options like “–enable-rpk”, “–enable-all”, or distro builds.
Medium-severity issues include bypasses of X.509 name constraints (CVE-2026-89133), improper enforcement of Common Name checks when only non-DNS Subject Alternative Names are present (CVE-2026-89134), unverified CA persistence (CVE-2026-89135), and a ChangeCipherSpec bypass (CVE-2026-93304). On the low end, fixes cover vulnerabilities like TLS shutdown use-after-free (CVE-2026-15442), OCSP/CRL check bypass (CVE-2026-94417), certificate signature bypass (CVE-2026-94418), and TLS session cache confusion attacks (CVE-2026-94419).
Post-Quantum Cryptography Gains
Beyond security patches, version 5.9.4 makes major strides toward quantum-resistant cryptography. It now includes native Falcon signature support, replacing prior reliance on liboqs. It also adds FrodoKEM as a post-quantum key encapsulation mechanism, with optimized builds for x86_64, AArch64, AArch32, and Thumb2 platforms. Additionally, SLH-DSA authentication is supported for TLS 1.3 and DTLS 1.3 handshakes across all parameter sets. Developers can now opt for post-quantum-only TLS 1.3 configurations using ML-KEM key exchange with ML-DSA or SLH-DSA authentication—no RSA, ECC, or traditional Diffie-Hellman needed. Performance-boost features include AVX-512 acceleration for ML-KEM and ML-DSA, plus ML-DSA support for PKCS#7 and CMS SignedData, and an “–enable-all-quantum-crypto” build option.
Upgrade Guidance
Users running wolfSSL version 5.9.2 or older should audit which build features are enabled and upgrade to 5.9.4 (or a downstream package with equivalent 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 flows. Because some state—such as certificates or session caches—may persist in memory, simply replacing shared libraries may not be enough; long-running processes or contexts (e.g. WOLFSSL_CTX) should be restarted post-upgrade.
The post-quantum improvements make this release especially noteworthy, signaling a growing industry shift toward cryptographic robustness amid concerns about future quantum threats. For all users of wolfSSL, ensuring secure configurations and staying current with version 5.9.4 will help minimize risk.
