wolfSSL has released version 5.9.4, addressing 11 security vulnerabilities across its TLS, DTLS, X.509 certificate validation, session-resumption, and revocation-checking code paths.
Several flaws could allow attackers to bypass peer authentication, forge certificates accepted by vulnerable clients, or cause revoked certificates to be trusted under specific configurations.
Released on September 25, 2026, wolfSSL 5.9.4 includes fixes for three high-severity vulnerabilities, five medium-severity issues, and three low-severity defects.
wolfSSL 5.9.4 Patches 11 Vulnerabilities
The most significant bugs affect deployments using DTLS, Raw Public Keys, OCSP stapling, custom certificate-verification callbacks, and legacy TLS session-cache APIs.
The highest-impact issue, tracked as CVE-2026-93302, affects the MatchTrustedPeer verification path. The flaw caused wolfSSL to ignore the public key associated with a trusted peer certificate, potentially allowing a forged certificate authority clone to pass validation.
The vulnerable configuration requires the WOLFSSL_TRUST_PEER_CERT feature and use of wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert() to load CA certificates.
When OpenSSL-compatible defaults are enabled, the exposure expands to all CA-loading operations. A malicious DTLS server that knows a client’s accepted CA certificates could exploit the flaw to bypass peer authentication. Affected releases range from wolfSSL 5.3.0 through 5.9.2.
CVE-2026-89102 affects OCSP multi-stapling support under RFC 6961. A client using the HAVE_CERTIFICATE_STATUS_REQUEST_V2 capability and OCSP stapling version 2 APIs could incorrectly accept any certificate in a peer chain as a CA.
An attacker holding a legitimate certificate and private key chained to a trusted CA could forge certificates for arbitrary identities, which the affected client might subsequently accept.
The vulnerable end-entity certificate could also persist in the trust store and impact future connections sharing the same context. Another high-severity flaw, CVE-2026-89136, impacts Raw Public Key deployments.
A TLS 1.2, TLS 1.3, or DTLS client could accept an unsolicited server_certificate_type=RawPublicKey value, enabling a malicious or improperly configured server to bypass authentication. The issue affects wolfSSL 5.6.0 through 5.9.2 where RPK support is enabled.
wolfSSL 5.9.4 also corrects certificate-chain validation issues involving X.509 NameConstraints. CVE-2026-89133 allowed a name-constrained intermediate CA’s restrictions to be lost if the certificate chain contained an unconstrained CA tier before the leaf certificate.
As a result, wolfSSL could accept hostnames outside the permitted namespace. CVE-2026-89134 addresses a related bypass introduced in version 5.9.2.
A certificate containing a Subject Alternative Name other than dNSName could bypass a DNS name-constraint validation check on the Subject Common Name.
CVE-2026-89135 affects applications using X509_verify_cert() with OpenSSL-extra compatibility enabled. A failed verification could place an unverified attacker-controlled CA into the shared certificate manager, potentially affecting native TLS, OCSP, CRL, and direct certificate-verification consumers.
CVE-2026-93304 enables a DTLS 1.2 authentication bypass through an out-of-order ChangeCipherSpec message.
Before deriving a master secret, a vulnerable client could install read keys generated from predictable material, allowing a network attacker to complete a handshake impersonating the server.
PSK deployments are especially exposed because a fake server can succeed without knowing the PSK.
The update additionally fixes OCSP-and-CRL validation bypasses, a session-cache reference flaw that could skip hostname and certificate checks during resumed TLS 1.2 sessions, and a certificate-signature verification issue in low-resource builds with permissive verification callbacks.
Organizations should upgrade to wolfSSL 5.9.4 immediately, particularly where DTLS, mutual TLS, OCSP plus CRL checking, RPK, or OpenSSL-compatible build profiles are used.
Teams unable to upgrade should review build flags, disable OpenSSL-compatible defaults where practical, avoid loading CA certificates through trusted-peer APIs, and restart long-running processes after patching because certain vulnerable trust-store and session-cache states can persist in memory.
Join 16,000+ SOC teams using ANY.RUN to streamline threat investigations and reduce manual effort. Explore for your team
