Filtered by vendor Wolfssl
Subscriptions
Filtered by product Wolfssl
Subscriptions
Total
72 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-1544 | 1 Wolfssl | 1 Wolfssl | 2025-12-06 | 4.1 Medium |
| Generating the ECDSA nonce k samples a random number r and then truncates this randomness with a modular reduction mod n where n is the order of the elliptic curve. Meaning k = r mod n. The division used during the reduction estimates a factor q_e by dividing the upper two digits (a digit having e.g. a size of 8 byte) of r by the upper digit of n and then decrements q_e in a loop until it has the correct size. Observing the number of times q_e is decremented through a control-flow revealing side-channel reveals a bias in the most significant bits of k. Depending on the curve this is either a negligible bias or a significant bias large enough to reconstruct k with lattice reduction methods. For SECP160R1, e.g., we find a bias of 15 bits. | ||||
| CVE-2024-5814 | 1 Wolfssl | 1 Wolfssl | 2025-12-06 | 5.3 Medium |
| A malicious TLS1.2 server can force a TLS1.3 client with downgrade capability to use a ciphersuite that it did not agree to and achieve a successful connection. This is because, aside from the extensions, the client was skipping fully parsing the server hello. https://doi.org/10.46586/tches.v2024.i1.457-500 | ||||
| CVE-2025-11931 | 1 Wolfssl | 1 Wolfssl | 2025-12-04 | 8.2 High |
| 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-11932 | 1 Wolfssl | 1 Wolfssl | 2025-12-04 | 4.3 Medium |
| 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-12888 | 1 Wolfssl | 1 Wolfssl | 2025-12-04 | 7.5 High |
| 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-12-04 | 5.4 Medium |
| 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-11935 | 3 Apple, Linux, Wolfssl | 3 Macos, Linux Kernel, Wolfssl | 2025-12-03 | 7.5 High |
| 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-11936 | 1 Wolfssl | 1 Wolfssl | 2025-12-03 | 5.3 Medium |
| 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-11934 | 3 Apple, Linux, Wolfssl | 3 Macos, Linux Kernel, Wolfssl | 2025-12-03 | 2.7 Low |
| 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 | 3 Apple, Linux, Wolfssl | 3 Macos, Linux Kernel, Wolfssl | 2025-12-03 | 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 | 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 | 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-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-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-2017-8854 | 1 Wolfssl | 1 Wolfssl | 2025-04-20 | N/A |
| 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. | ||||