Filtered by vendor Wolfssl
Subscriptions
Filtered by product Wolfssl
Subscriptions
Total
71 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-11935 | 1 Wolfssl | 1 Wolfssl | 2025-11-25 | N/A |
| With TLS 1.3 pre-shared key (PSK) a malicious or faulty server could ignore the request for PFS (perfect forward secrecy) and the client would continue on with the connection using PSK without PFS. This happened when a server responded to a ClientHello containing psk_dhe_ke without a key_share extension. The re-use of an authenticated PSK connection that on the clients side unexpectedly did not have PFS, reduces the security of the connection. | ||||
| CVE-2025-12888 | 1 Wolfssl | 1 Wolfssl | 2025-11-25 | N/A |
| Vulnerability in X25519 constant-time cryptographic implementations due to timing side channels introduced by compiler optimizations and CPU architecture limitations, specifically with the Xtensa-based ESP32 chips. If targeting Xtensa it is recommended to use the low memory implementations of X25519, which is now turned on as the default for Xtensa. | ||||
| CVE-2025-12889 | 1 Wolfssl | 1 Wolfssl | 2025-11-25 | N/A |
| With TLS 1.2 connections a client can use any digest, specifically a weaker digest that is supported, rather than those in the CertificateRequest. | ||||
| CVE-2025-11932 | 1 Wolfssl | 1 Wolfssl | 2025-11-25 | N/A |
| The server previously verified the TLS 1.3 PSK binder using a non-constant time method which could potentially leak information about the PSK binder | ||||
| CVE-2025-11931 | 1 Wolfssl | 1 Wolfssl | 2025-11-25 | N/A |
| Integer Underflow Leads to Out-of-Bounds Access in XChaCha20-Poly1305 Decrypt. This issue is hit specifically with a call to the function wc_XChaCha20Poly1305_Decrypt() which is not used with TLS connections, only from direct calls from an application. | ||||
| CVE-2025-11934 | 1 Wolfssl | 1 Wolfssl | 2025-11-25 | N/A |
| Improper input validation in the TLS 1.3 CertificateVerify signature algorithm negotiation in wolfSSL 5.8.2 and earlier on multiple platforms allows for downgrading the signature algorithm used. For example when a client sends ECDSA P521 as the supported signature algorithm the server previously could respond as ECDSA P256 being the accepted signature algorithm and the connection would continue with using ECDSA P256, if the client supports ECDSA P256. | ||||
| CVE-2025-11933 | 1 Wolfssl | 1 Wolfssl | 2025-11-25 | N/A |
| 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. | ||||
| CVE-2025-11936 | 1 Wolfssl | 1 Wolfssl | 2025-11-25 | N/A |
| 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. | ||||
| CVE-2025-7395 | 1 Wolfssl | 1 Wolfssl | 2025-07-22 | N/A |
| A certificate verification error in wolfSSL when building with the WOLFSSL_SYS_CA_CERTS and WOLFSSL_APPLE_NATIVE_CERT_VALIDATION options results in the wolfSSL client failing to properly verify the server certificate's domain name, allowing any certificate issued by a trusted CA to be accepted regardless of the hostname. | ||||
| CVE-2025-7396 | 1 Wolfssl | 1 Wolfssl | 2025-07-22 | N/A |
| In wolfSSL release 5.8.2 blinding support is turned on by default for Curve25519 in applicable builds. The blinding configure option is only for the base C implementation of Curve25519. It is not needed, or available with; ARM assembly builds, Intel assembly builds, and the small Curve25519 feature. While the side-channel attack on extracting a private key would be very difficult to execute in practice, enabling blinding provides an additional layer of protection for devices that may be more susceptible to physical access or side-channel observation. | ||||
| CVE-2025-7394 | 1 Wolfssl | 1 Wolfssl | 2025-07-22 | N/A |
| In the OpenSSL compatibility layer implementation, the function RAND_poll() was not behaving as expected and leading to the potential for predictable values returned from RAND_bytes() after fork() is called. This can lead to weak or predictable random numbers generated in applications that are both using RAND_bytes() and doing fork() operations. This only affects applications explicitly calling RAND_bytes() after fork() and does not affect any internal TLS operations. Although RAND_bytes() documentation in OpenSSL calls out not being safe for use with fork() without first calling RAND_poll(), an additional code change was also made in wolfSSL to make RAND_bytes() behave similar to OpenSSL after a fork() call without calling RAND_poll(). Now the Hash-DRBG used gets reseeded after detecting running in a new process. If making use of RAND_bytes() and calling fork() we recommend updating to the latest version of wolfSSL. Thanks to Per Allansson from Appgate for the report. | ||||
| CVE-2024-0901 | 1 Wolfssl | 1 Wolfssl | 2025-07-12 | 7.5 High |
| Remotely executed SEGV and out of bounds read allows malicious packet sender to crash or cause an out of bounds read via sending a malformed packet with the correct length. | ||||
| CVE-2022-39173 | 1 Wolfssl | 1 Wolfssl | 2025-05-20 | 7.5 High |
| 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. | ||||
| CVE-2022-42961 | 1 Wolfssl | 1 Wolfssl | 2025-05-14 | 5.3 Medium |
| An issue was discovered in wolfSSL before 5.5.0. A fault injection attack on RAM via Rowhammer leads to ECDSA key disclosure. Users performing signing operations with private ECC keys, such as in server-side TLS connections, might leak faulty ECC signatures. These signatures can be processed via an advanced technique for ECDSA key recovery. (In 5.5.0 and later, WOLFSSL_CHECK_SIG_FAULTS can be used to address the vulnerability.) | ||||
| CVE-2022-42905 | 1 Wolfssl | 1 Wolfssl | 2025-05-02 | 9.1 Critical |
| In wolfSSL before 5.5.2, if callback functions are enabled (via the WOLFSSL_CALLBACKS flag), then a malicious TLS 1.3 client or network attacker can trigger a buffer over-read on the heap of 5 bytes. (WOLFSSL_CALLBACKS is only intended for debugging.) | ||||
| CVE-2023-6937 | 1 Wolfssl | 1 Wolfssl | 2025-04-24 | 5.3 Medium |
| 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. | ||||
| CVE-2017-8855 | 1 Wolfssl | 1 Wolfssl | 2025-04-20 | N/A |
| wolfSSL before 3.11.0 does not prevent wc_DhAgree from accepting a malformed DH key. | ||||
| CVE-2014-2903 | 1 Wolfssl | 1 Wolfssl | 2025-04-20 | N/A |
| 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. | ||||
| CVE-2017-2800 | 1 Wolfssl | 1 Wolfssl | 2025-04-20 | 9.8 Critical |
| 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. | ||||
| CVE-2017-13099 | 3 Arubanetworks, Siemens, Wolfssl | 4 Instant, Scalance W1750d, Scalance W1750d Firmware and 1 more | 2025-04-20 | N/A |
| 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." | ||||