Filtered by vendor Wolfssl
Subscribe
Total
116 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-11933 | 3 Apple, Linux, Wolfssl | 3 Macos, Linux Kernel, Wolfssl | 2025-12-03 | N/A | 6.5 MEDIUM |
| 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-7396 | 1 Wolfssl | 1 Wolfssl | 2025-12-03 | N/A | 4.6 MEDIUM |
| 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-12-03 | N/A | 9.8 CRITICAL |
| 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-2022-39173 | 1 Wolfssl | 1 Wolfssl | 2025-05-20 | N/A | 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 | N/A | 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 | N/A | 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-6936 | 1 Wolfssl | 1 Wolfssl | 2025-03-26 | N/A | 5.3 MEDIUM |
| 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). | |||||
| CVE-2023-6937 | 1 Wolfssl | 1 Wolfssl | 2025-02-21 | N/A | 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-2023-6935 | 1 Wolfssl | 1 Wolfssl | 2024-11-21 | N/A | 5.9 MEDIUM |
| 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="-DWOLFSSL_STATIC_RSA" The define “WOLFSSL_STATIC_RSA” 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. | |||||
| CVE-2023-3724 | 1 Wolfssl | 1 Wolfssl | 2024-11-21 | N/A | 9.1 CRITICAL |
| If a TLS 1.3 client gets neither a PSK (pre shared key) extension nor a KSE (key share extension) when connecting to a malicious server, a default predictable buffer gets used for the IKM (Input Keying Material) value when generating the session master secret. Using a potentially known IKM value when generating the session master secret key compromises the key generated, allowing an eavesdropper to reconstruct it and potentially allowing access to or meddling with message contents in the session. This issue does not affect client validation of connected servers, nor expose private key information, but could result in an insecure TLS 1.3 session when not controlling both sides of the connection. wolfSSL recommends that TLS 1.3 client side users update the version of wolfSSL used. | |||||
| CVE-2022-38153 | 1 Wolfssl | 1 Wolfssl | 2024-11-21 | N/A | 5.9 MEDIUM |
| An issue was discovered in wolfSSL before 5.5.0 (when --enable-session-ticket is used); however, only version 5.3.0 is exploitable. Man-in-the-middle attackers or a malicious server can crash TLS 1.2 clients during a handshake. If an attacker injects a large ticket (more than 256 bytes) into a NewSessionTicket message in a TLS 1.2 handshake, and the client has a non-empty session cache, the session cache frees a pointer that points to unallocated memory, causing the client to crash with a "free(): invalid pointer" message. NOTE: It is likely that this is also exploitable during TLS 1.3 handshakes between a client and a malicious server. With TLS 1.3, it is not possible to exploit this as a man-in-the-middle. | |||||
| CVE-2022-38152 | 1 Wolfssl | 1 Wolfssl | 2024-11-21 | N/A | 7.5 HIGH |
| An issue was discovered in wolfSSL before 5.5.0. When a TLS 1.3 client connects to a wolfSSL server and SSL_clear is called on its session, the server crashes with a segmentation fault. This occurs in the second session, which is created through TLS session resumption and reuses the initial struct WOLFSSL. If the server reuses the previous session structure (struct WOLFSSL) by calling wolfSSL_clear(WOLFSSL* ssl) on it, the next received Client Hello (that resumes the previous session) crashes the server. Note that this bug is only triggered when resuming sessions using TLS session resumption. Only servers that use wolfSSL_clear instead of the recommended SSL_free; SSL_new sequence are affected. Furthermore, wolfSSL_clear is part of wolfSSL's compatibility layer and is not enabled by default. It is not part of wolfSSL's native API. | |||||
| CVE-2022-34293 | 1 Wolfssl | 1 Wolfssl | 2024-11-21 | N/A | 7.5 HIGH |
| wolfSSL before 5.4.0 allows remote attackers to cause a denial of service via DTLS because a check for return-routability can be skipped. | |||||
| CVE-2022-25640 | 1 Wolfssl | 1 Wolfssl | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| In wolfSSL before 5.2.0, a TLS 1.3 server cannot properly enforce a requirement for mutual authentication. A client can simply omit the certificate_verify message from the handshake, and never present a certificate. | |||||
| CVE-2022-25638 | 1 Wolfssl | 1 Wolfssl | 2024-11-21 | 4.3 MEDIUM | 6.5 MEDIUM |
| In wolfSSL before 5.2.0, certificate validation may be bypassed during attempted authentication by a TLS 1.3 client to a TLS 1.3 server. This occurs when the sig_algo field differs between the certificate_verify message and the certificate message. | |||||
| CVE-2022-23408 | 1 Wolfssl | 1 Wolfssl | 2024-11-21 | 6.4 MEDIUM | 9.1 CRITICAL |
| wolfSSL 5.x before 5.1.1 uses non-random IV values in certain situations. This affects connections (without AEAD) using AES-CBC or DES3 with TLS 1.1 or 1.2 or DTLS 1.1 or 1.2. This occurs because of misplaced memory initialization in BuildMessage in internal.c. | |||||
| CVE-2021-45939 | 1 Wolfssl | 1 Wolfmqtt | 2024-11-21 | 4.3 MEDIUM | 5.5 MEDIUM |
| wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttClient_DecodePacket (called from MqttClient_WaitType and MqttClient_Subscribe). | |||||
| CVE-2021-45938 | 1 Wolfssl | 1 Wolfmqtt | 2024-11-21 | 4.3 MEDIUM | 5.5 MEDIUM |
| wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttClient_DecodePacket (called from MqttClient_WaitType and MqttClient_Unsubscribe). | |||||
| CVE-2021-45937 | 1 Wolfssl | 1 Wolfmqtt | 2024-11-21 | 4.3 MEDIUM | 5.5 MEDIUM |
| wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttClient_DecodePacket (called from MqttClient_WaitType and MqttClient_Connect). | |||||
| CVE-2021-45936 | 1 Wolfssl | 1 Wolfmqtt | 2024-11-21 | 4.3 MEDIUM | 5.5 MEDIUM |
| wolfSSL wolfMQTT 1.9 has a heap-based buffer overflow in MqttDecode_Disconnect (called from MqttClient_DecodePacket and MqttClient_WaitType). | |||||