In wolfSSL before 5.5.1, malicious clients can cause a buffer overflow during a TLS 1.3 handshake. This occurs when an attacker supposedly resumes a previous TLS session. During the resumption Client Hello a Hello Retry Request must be triggered. Both Client Hellos are required to contain a list of duplicate cipher suites to trigger the buffer overflow. In total, two Client Hellos have to be sent: one in the resumed session, and a second one as a response to a Hello Retry Request message.

wolfSSL prior to 5.6.6 did not check that messages in one (D)TLS record do not span key boundaries. As a result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the server containing first a ServerHello message and then the rest of the first server flight would be accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL client would accept an unencrypted flight from the server. This does not compromise key negotiation and authentication so it is assigned a low severity rating.

In wolfSSL prior to 5.6.6, if callback functions are enabled (via the WOLFSSLCALLBACKS flag), then a malicious TLS client or network attacker can trigger a buffer over-read on the heap of 5 bytes (WOLFSSLCALLBACKS is only intended for debugging).

An issue was discovered in wolfSSL before 5.7.0. A safe-error attack via Rowhammer, namely FAULT+PROBE, leads to ECDSA key disclosure. When WOLFSSLCHECKSIGFAULTS is used in signing operations with private ECC keys,

such as in server-side TLS connections, the connection is halted if any fault occurs. The success rate in a certain amount of connection requests can be processed via an advanced technique for ECDSA key recovery.

wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow (8 bytes) in MqttDecodePublish (called from MqttClientDecodePacket and MqttClientHandlePacket).

wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttClientDecodePacket (called from MqttClientHandlePacket and MqttClientWaitType).

wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttClientDecodePacket (called from MqttClientWaitType and MqttClientConnect).

wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttClientDecodePacket (called from MqttClientWaitType and MqttClientSubscribe).

wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttDecodeDisconnect (called from MqttClientDecodePacket and MqttClientWaitType).

wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttClientDecodePacket (called from MqttClientWaitType and MqttClientUnsubscribe).

wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow (4 bytes) in MqttDecodePublish (called from MqttClientDecodePacket and MqttClientHandlePacket).

examples/benchmark/tlsbench.c in a benchmark tool in wolfSSL through 3.15.7 has a heap-based buffer overflow.

wolfSSL SP Math All RSA implementation is vulnerable to the Marvin Attack, new variation of a timing Bleichenbacher style attack, when built with the following options to configure:

--enable-all CFLAGS="-DWOLFSSLSTATICRSA"

The define “WOLFSSLSTATICRSA” enables static RSA cipher suites, which is not recommended, and has been disabled by default since wolfSSL 3.6.6.  Therefore the default build since 3.6.6, even with "--enable-all", is not vulnerable to the Marvin Attack. The vulnerability is specific to static RSA cipher suites, and expected to be padding-independent.

The vulnerability allows an attacker to decrypt ciphertexts and forge signatures after probing with a large number of test observations. However the server’s private key is not exposed.

wolfSSL before 3.10.2 has an out-of-bounds memory access with loading crafted DH parameters, aka a buffer overflow triggered by a malformed temporary DH file.

wolfcrypt/src/ecc.c in wolfSSL before 3.15.1.patch allows a memory-cache side-channel attack on ECDSA signatures, aka the Return Of the Hidden Number Problem or ROHNP. To discover an ECDSA key, the attacker needs access to either the local machine or a different virtual machine on the same physical host.

wolfSSL before 3.11.0 does not prevent wcDhAgree from accepting a malformed DH key.

wolfSSL prior to version 3.12.2 provides 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. This vulnerability is referred to as "ROBOT."

Fault Injection vulnerability in wced25519signmsg function in wolfssl/wolfcrypt/src/ed25519.c in WolfSSL wolfssl5.6.6 on Linux/Windows allows remote attacker co-resides in the same system with a victim process to disclose information and escalate privileges via Rowhammer fault injection to the ed25519key structure.

The side-channel protected T-Table implementation in wolfSSL up to version 5.6.5 protects against a side-channel attacker with cache-line resolution. In a controlled environment such as Intel SGX, an attacker can gain a per instruction sub-cache-line resolution allowing them to break the cache-line-level protection. For details on the attack refer to: https://doi.org/10.46586/tches.v2024.i1.457-500

CyaSSL does not check the key usage extension in leaf certificates, which allows remote attackers to spoof servers via a crafted server certificate not authorized for use in an SSL/TLS handshake.

The SSL 3 HMAC functionality in wolfSSL CyaSSL 2.5.0 before 2.9.4 does not check the padding length when verification fails, which allows remote attackers to have unspecified impact via a crafted HMAC, which triggers an out-of-bounds read.

The DoAlert function in the (1) TLS and (2) DTLS implementations in wolfSSL CyaSSL before 2.9.4 allows remote attackers to have unspecified impact and vectors, which trigger memory corruption or an out-of-bounds read.

wolfSSL CyaSSL before 2.9.4 allows remote attackers to have unspecified impact via multiple calls to the CyaSSLread function which triggers an out-of-bounds read when an error occurs, related to not checking the return code and MAC verification failure.

wolfSSL (formerly CyaSSL) before 3.6.8 does not properly handle faults associated with the Chinese Remainder Theorem (CRT) process when allowing ephemeral key exchange without low memory optimizations on a server, which makes it easier for remote attackers to obtain private RSA keys by capturing TLS handshakes, aka a Lenstra attack.

wolfSSL (formerly CyaSSL) before 3.6.8 allows remote attackers to cause a denial of service (resource consumption or traffic amplification) via a crafted DTLS cookie in a ClientHello message.

The C software implementation of AES Encryption and Decryption in wolfSSL (formerly CyaSSL) before 3.9.10 makes it easier for local users to discover AES keys by leveraging cache-bank timing differences.

The C software implementation of ECC in wolfSSL (formerly CyaSSL) before 3.9.10 makes it easier for local users to discover RSA keys by leveraging cache-bank hit differences.

The C software implementation of RSA in wolfSSL (formerly CyaSSL) before 3.9.10 makes it easier for local users to discover RSA keys by leveraging cache-bank hit differences.

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. In order to trigger this vulnerability, the attacker needs to supply a malicious x509 certificate to either a server or a client application using this library.

It was found that wolfssl before 3.15.7 is vulnerable to a new variant of the Bleichenbacher attack to perform downgrade attacks against TLS. This may lead to leakage of sensible data.