wolfSSL vulnerabilities

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.

A certificate with no dNSName SAN but another SAN type present bypassed the Subject CN dNSName name-constraint check. This incomplete fix from CVE-2026-6731 was introduced in wolfSSL version 5.9.2.

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.

An issue in the ConfirmNameConstraints() function (wolfcrypt/src/asn.c) of wolfSSL v5.9.1 and v5.9.2 allows attackers to cause a Denial of Service (DoS) via providing crafted Certificate Authority certificates, leading to valid certificates without SAN to be incorrectly rejected by wolfSSL-based TLS clients.

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.

A failed X509_verify_cert call permanently plants an unverified attacker CA in the shared CertManager, bypassing certificate validation in all type-blind sibling consumers. Affects wolfSSL versions 5.8.4 through 5.9.2 with specific macros or --enable-opensslextra, when the application calls X509_verify_cert.

wolfSSL versions 5.9.2 and earlier fail to properly enforce NameConstraints extensions when there is an unconstrained CA tier between a name-constrained intermediate CA and the leaf certificate. wolfSSL incorrectly accepts certificates for hostnames they shouldn't cover due to a chain-walking state-machine bug.

In wolfSSL versions 5.7.2 through 5.9.2, a client-side implementation flaw in RFC 6961 (multiple OCSP response stapling) can lead to certificate forgery. When a client enables OCSP stapling with HAVE_CERTIFICATE_STATUS_REQUEST_V2 and calls wolfSSL_UseOCSPStaplingV2, it accepts any certificate in the peer's chain as a CA without verifying authorization.

In all builds using (D)TLS, including default builds, there is a series of conditional states during TLS shutdown that could lead to a heap-use-after-free. If an application gets a partial wolfSSL_read() result, sometimes caused by a small user buffer, then calls wolfSSL_shutdown for a bidirectional close and attempts wolfSSL_read() again while the peer continues sending data during shutdown, it could lead to a heap-use-after-free.

In wolfSSL versions v5.3.0 through v5.9.2, when NO_SESSION_CACHE_REF is undefined, wolfSSL_get_session() returns a handle into the process-global SessionCache instead of a session object. Because the TLS 1.2 session ID is server-chosen and sent in clear, a malicious server can overwrite the client's cache entry for another server and then be accepted as the original server during session resumption without certificate or domain name verification.

A vulnerability in wolfSSL when WOLFSSL_SMALL_CERT_VERIFY is enabled allows an attacker to bypass certificate signature verification. Due to incorrect result merging, parse errors hide invalid signatures, and date/constraint checks are performed before signature confirmation. An attacker can use a self-signed certificate with arbitrary signature bytes to pass verification if the application uses a callback that overrides date errors.

The wc_Blake2bHmacFinal and wc_Blake2sHmacFinal functions in the wolfSSL library have an issue when the key length exceeds the block size, resulting in a MAC that is independent of the input data. When a key is too long, the hashing state is reset, causing the loss of message data.

A vulnerability in the wolfSSL library allows bypassing IP address name constraints when the WOLFSSL_IP_ALT_NAME macro is not defined. In this configuration, a certificate can violate IP address constraints imposed by a certificate authority.

Integer underflow in wc_PKCS7_DecryptOri when processing crafted Other Recipient Info, leading to incorrect length handling during decryption.

A vulnerability in the wolfSSL library causes URI nameConstraints from constrained intermediate CAs to be parsed but not enforced during certificate chain verification. A compromised or malicious sub-CA could issue leaf certificates with URI SAN entries that violate the nameConstraints of the issuing CA, and wolfSSL would accept them as valid.

Multiple constant-time implementations in wolfSSL before version 5.8.4 may be transformed into non-constant-time binary by LLVM optimizations, which can potentially result in observable timing discrepancies and lead to information disclosure through timing side-channel attacks.

Improper input validation in the TLS 1.3 KeyShareEntry parsing in wolfSSL v5.8.2 on multiple platforms allows a remote unauthenticated attacker to cause a denial-of-service by sending a crafted ClientHello message containing duplicate KeyShareEntry values for the same supported group, leading to excessive CPU and memory consumption during ClientHello processing.

wolfSSL 5.8.2 and earlier on multiple platforms has improper input validation in the TLS 1.3 CertificateVerify signature algorithm negotiation. This allows downgrading the signature algorithm, e.g., a server may accept ECDSA P256 when the client offered ECDSA P521.

Improper input validation in the TLS 1.3 CKS extension parsing in wolfSSL 5.8.2 and earlier on multiple platforms allows a remote unauthenticated attacker to potentially cause a denial-of-service via a crafted ClientHello message with duplicate CKS extensions.