Aggregating NVD, CVE, and multi-source threat feeds, this list provides deep analysis of high-risk threats such as RCE. By integrating CVSS and EPSS models, the system dynamically tracks Exp (Exploit) resources and PoC availability to accurately assess Exploitability. Combined with official Patches and remediation strategies, it helps prioritize Vulnerability Management workflows, significantly shortening response cycles and securing your critical assets.
Assigner (CNA / source)：[email protected] Remove this filter
| CVE | Description | Max CVSS | EPSS % | Published | Updated |
|---|---|---|---|---|---|
| CVE-2024-5991 | In function MatchDomainName(), input param str is treated as a NULL terminated string despite being user provided and unchecked. Specifically, the function X509_check_host() takes in a pointer and length to check against, with no requirements that it be NULL terminated. If a caller was attempting to do a name check on a non-NULL terminated buffer, the code would read beyond the bounds of the input array until it found a NULL terminator.This issue affects wolfSSL: through 5.7.0. | 10.0 | 0.56% | 2024-08-27 | 2026-06-17 |
| CVE-2025-14942 | wolfSSH’s key exchange state machine can be manipulated to leak the client’s password in the clear, trick the client to send a bogus signature, or trick the client into skipping user authentication. This affects client applications with wolfSSH version 1.4.21 and earlier. Users of wolfSSH must update or apply the fix patch and it’s recommended to update credentials used. This fix is also recommended for wolfSSH server applications. While there aren’t any specific attacks on server applications, | 9.4 | 0.35% | 2026-01-06 | 2026-06-17 |
| CVE-2025-11625 | Improper host authentication vulnerability in wolfSSH version 1.4.20 and earlier clients that allows authentication bypass and leaking of clients credentials. | 9.4 | 0.38% | 2025-10-21 | 2026-06-17 |
| CVE-2026-5194 | Missing hash/digest size and OID checks allow digests smaller than allowed when verifying ECDSA certificates, or smaller than is appropriate for the relevant key type, to be accepted by signature verification functions. This could lead to reduced security of ECDSA certificate-based authentication if the public CA key used is also known. This affects ECDSA/ECC verification when EdDSA or ML-DSA is also enabled. | 9.3 | 0.47% | 2026-04-09 | 2026-06-17 |
| CVE-2025-15346 | A vulnerability in the handling of verify_mode = CERT_REQUIRED in the wolfssl Python package (wolfssl-py) causes client certificate requirements to not be fully enforced. Because the WOLFSSL_VERIFY_FAIL_IF_NO_PEER_CERT flag was not included, the behavior effectively matched CERT_OPTIONAL: a peer certificate was verified if presented, but connections were incorrectly authenticated when no client certificate was provided. This results in improper authentication, allowing attackers to bypass mu | 9.3 | 0.27% | 2026-01-07 | 2026-06-17 |
| CVE-2025-7395 | 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. | 9.2 | 0.18% | 2025-07-18 | 2026-06-17 |
| CVE-2024-2873 | A vulnerability was found in wolfSSH's server-side state machine before versions 1.4.17. A malicious client could create channels without first performing user authentication, resulting in unauthorized access. | 9.1 | 0.63% | 2024-03-25 | 2026-06-17 |
| CVE-2023-3724 | 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 | 9.1 | 0.54% | 2023-07-17 | 2026-06-17 |
| CVE-2026-6679 | A heap buffer overflow could occur in the DTLS 1.3 ACK serialization path before the connecting peer is authenticated. The buffer overflow was due to an integer truncation when computing the length of the ACK record-number list, causing an undersized buffer to be allocated and then overrun. This affects builds using DTLS 1.3 and wolfSSL version 5.9.0 and earlier. A fix was added to the 5.9.1 release. | 8.8 | 0.39% | 2026-06-25 | 2026-06-27 |
| CVE-2026-5500 | wolfSSL's wc_PKCS7_DecodeAuthEnvelopedData() does not properly sanitize the AES-GCM authentication tag length received and has no lower bounds check. A man-in-the-middle can therefore truncate the mac field from 16 bytes to 1 byte, reducing the tag check from 2⁻¹²⁸ to 2⁻⁸. | 8.7 | 0.36% | 2026-04-10 | 2026-06-17 |
| CVE-2026-11310 | X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wolfSSL TLS/DTLS usage is not impacted. wolfSSL's X509_verify_cert() temporarily loads each caller-supp | 8.7 | 0.14% | 2026-06-25 | 2026-06-26 |
| CVE-2026-5501 | wolfSSL_X509_verify_cert in the OpenSSL compatibility layer accepts a certificate chain in which the leaf's signature is not checked, if the attacker supplies an untrusted intermediate with Basic Constraints `CA:FALSE` that is legitimately signed by a trusted root. An attacker who obtains any leaf certificate from a trusted CA (e.g. a free DV cert from Let's Encrypt) can forge a certificate for any subject name with any public key and arbitrary signature bytes, and the function returns `WOLFSSL_ | 8.6 | 0.18% | 2026-04-10 | 2026-06-17 |
| CVE-2026-55958 | Out-of-bounds write in the Renesas TSIP TLS 1.3 transcript buffer. In tsip_StoreMessage() the capacity check guarding the fixed message bag (MSGBAG_SIZE) sets an error code but fails to return, so execution falls through to an XMEMCPY that writes past the end of the buffer once the accumulated TLS 1.3 handshake transcript exceeds MSGBAG_SIZE (8 KB), corrupting adjacent heap state and potentially causing a remote denial of service crash. The bag is sized to hold a normal handshake, so this is rea | 8.3 | 0.29% | 2026-06-25 | 2026-06-26 |
| CVE-2026-5264 | Heap buffer overflow in DTLS 1.3 ACK message processing. A remote attacker can send a crafted DTLS 1.3 ACK message that triggers a heap buffer overflow. | 8.3 | 0.45% | 2026-04-09 | 2026-06-17 |
| CVE-2026-3549 | Heap Overflow in TLS 1.3 ECH parsing. An integer underflow existed in ECH extension parsing logic when calculating a buffer length, which resulted in writing beyond the bounds of an allocated buffer. Note that in wolfSSL, ECH is off by default, and the ECH standard is still evolving. | 8.3 | 0.49% | 2026-03-19 | 2026-06-17 |
| CVE-2026-10097 | wolfSSL's AVX2-optimized ML-KEM implementation (mlkem_cmp_avx2) compares only 1536 of the 1568 ciphertext bytes during the Fujisaki-Okamoto re-encryption check in ML-KEM-1024 decapsulation. Ciphertexts that differ from the expected re-encryption solely in bytes 1536-1567 bypass implicit rejection and are accepted as valid, breaking IND-CCA2 security. An attacker able to submit chosen ciphertexts to a decapsulation oracle that uses a static ML-KEM-1024 key, and to observe whether the genuine shar | 8.3 | 0.15% | 2026-06-25 | 2026-06-26 |
| CVE-2026-55961 | wolfSSL_PKCS7_verify() returning success for a degenerate (certs-only) PKCS#7 object that contains no signer. Such an object has empty signerInfos, so the underlying signed-data verification succeeds without authenticating any content. The compatibility-layer verify path now rejects the object when no signer signature has actually been verified, so a PKCS#7 carrying no valid signature is no longer reported as verified. This is enforced regardless of the PKCS7_NOVERIFY flag, which only suppresses | 8.2 | 0.12% | 2026-06-25 | 2026-06-26 |
| CVE-2026-55960 | Un-negotiated Raw Public Key (RFC 7250) accepted in place of an X.509 certificate, bypassing chain validation. A raw public key has no chain, so ParseCertRelative() accepts it without performing any trust verification; it must therefore only be accepted when RPK was actually negotiated for that peer. The check now defaults the expected type to X.509 (per RFC 7250/8446) when no type was negotiated, comparing against the received server certificate type on the client and the selected client certif | 8.2 | 0.14% | 2026-06-25 | 2026-06-26 |
| CVE-2026-5477 | An integer overflow existed in the wolfCrypt CMAC implementation, that could be exploited to forge CMAC tags. The function wc_CmacUpdate used the guard `if (cmac->totalSz != 0)` to skip XOR-chaining on the first block (where digest is all-zeros and the XOR is a no-op). However, totalSz is word32 and wraps to zero after 2^28 block flushes (4 GiB), causing the guard to erroneously discard the live CBC-MAC chain state. Any two messages sharing a common suffix beyond the 4 GiB mark then produce iden | 8.2 | 0.37% | 2026-04-10 | 2026-06-17 |
| CVE-2026-11999 | X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_cert() returned success based only on the last verified link rather than on reaching a trust anchor: w | 8.2 | 0.14% | 2026-06-25 | 2026-06-26 |