Note:
This project will be discontinued after December 13, 2021. [more]
Product:
Wolfssl
(Wolfssl)Repositories | https://github.com/wolfSSL/wolfssl |
#Vulnerabilities | 59 |
Date | Id | Summary | Products | Score | Patch | Annotated |
---|---|---|---|---|---|---|
2024-08-27 | CVE-2024-5288 | 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 WOLFSSL_CHECK_SIG_FAULTS 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 | 5.9 | ||
2024-02-15 | CVE-2023-6937 | 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... | Wolfssl | 5.3 | ||
2024-02-20 | CVE-2023-6936 | In wolfSSL prior to 5.6.6, if callback functions are enabled (via the WOLFSSL_CALLBACKS flag), then a malicious TLS client or network attacker can trigger a buffer over-read on the heap of 5 bytes (WOLFSSL_CALLBACKS is only intended for debugging). | Wolfssl | 9.1 | ||
2020-08-21 | CVE-2020-15309 | An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Local attackers can conduct a cache-timing attack against public key operations. These attackers may already have obtained sensitive information if the affected system has been used for private key operations (e.g., signing with a private key). | Wolfssl | 7.0 | ||
2020-08-21 | CVE-2020-24585 | An issue was discovered in the DTLS handshake implementation in wolfSSL before 4.5.0. Clear DTLS application_data messages in epoch 0 do not produce an out-of-order error. Instead, these messages are returned to the application. | Wolfssl | 5.3 | ||
2020-08-24 | CVE-2020-24613 | wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in tls13.c. This is an incorrect implementation of the TLS 1.3 client state machine. This allows attackers in a privileged network position to completely impersonate any TLS 1.3 servers, and read or modify potentially sensitive information between clients using the wolfSSL library and these TLS servers. | Wolfssl | 6.8 | ||
2021-01-06 | CVE-2020-36177 | RsaPad_PSS in wolfcrypt/src/rsa.c in wolfSSL before 4.6.0 has an out-of-bounds write for certain relationships between key size and digest size. | Wolfssl | 9.8 | ||
2021-01-29 | CVE-2021-3336 | DoTls13CertificateVerify in tls13.c in wolfSSL before 4.7.0 does not cease processing for certain anomalous peer behavior (sending an ED22519, ED448, ECC, or RSA signature without the corresponding certificate). The client side is affected because man-in-the-middle attackers can impersonate TLS 1.3 servers. | Wolfssl | 8.1 | ||
2021-07-14 | CVE-2021-24116 | In wolfSSL through 4.6.0, a side-channel vulnerability in base64 PEM file decoding allows system-level (administrator) attackers to obtain information about secret RSA keys via a controlled-channel and side-channel attack on software running in isolated environments that can be single stepped, especially Intel SGX. | Wolfssl | 4.9 | ||
2021-07-21 | CVE-2021-37155 | wolfSSL 4.6.x through 4.7.x before 4.8.0 does not produce a failure outcome when the serial number in an OCSP request differs from the serial number in the OCSP response. | Wolfssl | 9.8 |