CVE-2026-89134

wolfSSL versions prior to 3.12.2 provide a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange is negotiated. An attacker can recover the private key from a vulnerable wolfSSL application.

wolfSSL versions before 3.11.0 do not prevent wc_DhAgree from accepting a malformed DH key.

wolfSSL versions before 3.10.2 have an out-of-bounds memory access issue when loading crafted DH parameters, leading to a buffer overflow triggered by a malformed temporary DH file.

wolfSSL versions (formerly CyaSSL) before 3.6.8 are vulnerable to a denial of service attack that can be triggered by a crafted DTLS cookie in a ClientHello message.

CVE-2023-3724 affects TLS 1.3 clients that do not receive a PSK or KSE extension when connecting to a malicious server. In this case, a default predictable buffer is used for the IKM value, which may lead to session key compromise.

A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting in potential certificate validation vulnerabilities, denial of service and possible remote code execution.

A vulnerability in wolfSSL causes CRL checking to be skipped for certificates without an OCSP URL when both OCSP and CRL revocation checking are enabled. As a result, a certificate revoked by CRL may be accepted, and a missing OCSP responder is treated as a positive response. The issue affects versions up to 5.9.2 and is reachable over TLS 1.0-1.3 and DTLS.

A (D)TLS 1.2 client can accept a ChangeCipherSpec message before sending its ClientKeyExchange, allowing an attacker to complete the handshake in place of the server and send data the client accepts as authentic. DTLS 1.2 clients are exposed via datagram reads, and TLS 1.2 clients when using wolfSSL_inject() or read ahead.

MatchTrustedPeer ignores the public key used, allowing forged CA clones to pass verification. Affected builds enable WOLFSSL_TRUST_PEER_CERT and load CA certificates via wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). The peer must know the loaded certificates to exploit the issue.

When using RPK, the client side of TLS 1.2, 1.3 and DTLS 1.2 connections could accept an unsolicited server_cert_type=RawPublicKey, allowing a malicious or misbehaving server to bypass authentication. RPK is off by default and only enabled in specific builds.