wolfSSL before 4.3.0 mishandles calls to wc_SignatureGenerateHash, leading to fault injection in RSA cryptography.

In wolfSSL before 4.3.0, wc_ecc_mulmod_ex does not properly resist side-channel attacks.

wolfSSL and wolfCrypt 4.1.0 and earlier (formerly known as CyaSSL) generate biased DSA nonces. This allows a remote attacker to compute the long term private key from several hundred DSA signatures via a lattice attack. The issue occurs because dsa.c fixes two bits of the generated nonces.

wolfssl before 3.2.0 has a server certificate that is not properly authorized for server authentication.

wolfssl before 3.2.0 does not properly authorize CA certificate for signing other certificates.

wolfssl before 3.2.0 does not properly issue certificates for a server's hostname.

wolfSSL and wolfCrypt 4.0.0 and earlier (when configured without --enable-fpecc, --enable-sp, or --enable-sp-math) contain a timing side channel in ECDSA signature generation. This allows a local attacker, able to precisely measure the duration of signature operations, to infer information about the nonces used and potentially mount a lattice attack to recover the private key used. The issue occurs because ecc.c scalar multiplication might leak the bit length.

In wolfSSL through 4.1.0, there is a missing sanity check of memory accesses in parsing ASN.1 certificate data while handshaking. Specifically, there is a one-byte heap-based buffer over-read in CheckCertSignature_ex in wolfcrypt/src/asn.c.

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

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.

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 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."

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.

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.

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

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.

In versions of wolfSSL before 3.10.2 the function fp_mul_comba makes it easier to extract RSA key information for a malicious user who has access to view cache on a machine.

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 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.

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.