Search vulnerabilities

Results 174

Export CSV
CVE-2026-10097

ML-KEM-1024 x64 AVX2 incomplete cipher text comparison enables IND-CCA2 break and static private-key recovery

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 shared secret or the implicit-rejection secret was produced, can use this as a plaintext-checking oracle to recover the private key. A proof of concept recovered a full ML-KEM-1024 private key with approximately 98% success using roughly 350 chosen ciphertexts. The flaw is a deterministic logic error and does not rely on timing measurements.

CVSS 4.0 · 8.3 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-10592

Wildcard DNS SAN bypasses CA name-constraint checks

Certificates with wildcard DNS SANs (e.g. *.example.com) bypassed CA name-constraint checks. A certificate with a wildcard DNS SAN that should be rejected by the issuing CA's permitted/excluded DNS name constraints could be accepted.

CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-11310

X.509 trust-chain bypass in wolfSSL_X509_verify_cert() via untrusted intermediate anchoring

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-supplied untrusted intermediate into the certificate manager but failed to drop them before the trusted-store check, so an untrusted intermediate could anchor the path itself. An attacker can present a chain that never reaches a configured trust anchor and have it accepted, resulting in acceptance of an attacker-controlled certificate. This is certificate verification independent of TLS (e.g. S/MIME/CMS, code/firmware signing, JWT/JWS x5c), is not specific to any key type or algorithm, and a single untrusted intermediate suffices. The default wolfSSL TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only TLS applications doing manual or deferred peer verification through this API are, which also requires --enable-sessioncerts.

CVSS 4.0 · 8.7 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-12340

Out-of-bounds heap read in SM2/SM3 certificate Subject Key Identifier computation

Out-of-bounds heap read during SM2/SM3 certificate signature verification. When parsing a certificate with an SM3wSM2 signature, the Subject Key Identifier computation reads the trailing 65 bytes of the public key without checking that the key is at least that long. A public key shorter than 65 bytes results in an out-of-bounds heap read, leading to a potential crash (denial of service); there is no out-of-bounds write. Note this only affects builds with SM2 support (--enable-sm2 or --enable-all).

CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-55958

Renesas TSIP TLS 1.3 transcript buffer out-of-bounds write in tsip_StoreMessage

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 reached only by an unusually large but valid certificate chain, or by a malicious or man-in-the-middle server sending an oversized handshake message to a client that does not strictly verify the chain. This only affects builds using the Renesas TSIP TLS port (WOLFSSL_RENESAS_TSIP_TLS) as a TLS 1.3 client on Renesas MCUs with TSIP hardware enabled, and is rated High within those builds. All other configurations are unaffected.

CVSS 4.0 · 8.3 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-55960

Un-negotiated Raw Public Key (RFC 7250) accepted in place of X.509, bypassing chain validation

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 certificate type on the server, and rejects any mismatch, including an un-negotiated raw public key, with UNSUPPORTED_CERTIFICATE. Only affects builds with Raw Public Key support (HAVE_RPK) enabled - disabled by default in a standalone build, but included in --enable-all.

CVSS 4.0 · 8.2 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-55964

Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA (temporary CA exemption)

Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA. Intermediate CA certificates are required to have the keyCertSign key usage when a Key Usage extension is present, but chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building a certificate path were previously exempted from this check, so an intermediate asserting CA:TRUE but lacking keyCertSign was accepted as a signing CA. The check now applies to chain-supplied temporary CAs as well; only operator-loaded root certificates (WOLFSSL_USER_CA) and self-signed roots remain exempt. Per RFC 5280 an absent Key Usage extension implies all usages, so the requirement is enforced only when the extension is actually present (extKeyUsageSet). Affects the OpenSSL-compatibility certificate-path-building path (X509_verify_cert / X509_STORE, OPENSSL_EXTRA/OPENSSL_ALL), where untrusted chain intermediates are added as temporary CAs; native (non-OpenSSL-compat) certificate verification does not create temporary CAs and is unaffected. Within those builds, the check applies unless ALLOW_INVALID_CERTSIGN is defined.

CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-6331

HMAC zero-length tag forgery in EVP_DigestVerifyFinal

HMAC zero-length tag forgery in EVP_DigestVerifyFinal, where a zero-length tag could be accepted as valid during HMAC verification. In the OpenSSL-compatibility HMAC verify path the supplied signature length was only checked as not exceeding the MAC length, so a zero-length or otherwise truncated tag could pass verification. The fix requires the supplied tag length to exactly equal the MAC length and rejects a zero-length MAC, so a forged short or empty tag is no longer accepted.

CVSS 4.0 · 2.1 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-10512

X25519 x86_64 assembly final reduction leaves non-canonical field element

The X25519 x86_64 assembly implementation fails to clear the most significant bit during the final modular reduction, so the computed result may not be fully reduced modulo the field prime 2^255 - 19. This can leave the field element in a non-canonical form, producing an incorrect result from the scalar multiplication and potentially a wrong shared secret. The final carry-propagation chains in the x64 and AVX2 reduction routines could overflow into the top bit, and the high limb was not masked afterward, so the 255-bit field element was left non-canonical.

CVSS 4.0 · 2.3 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-7531

Use-after-free in PQC hybrid key-share handling

Use-after-free in PQC hybrid key-share handling. This is an incomplete-fix follow-up to CVE-2026-5460 (released in 5.9.1): a malicious TLS 1.3 server sending a truncated PQC hybrid KeyShare can still trigger the error cleanup path to operate on freed memory.

CVSS 4.0 · 2.3 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-6731

X.509 name constraint bypass via Subject CN treated as a DNS name

X.509 name constraint bypass via the Subject Common Name when treated as a DNS-type name. A certificate whose Subject CN violates an issuing CA's DNS name constraints could be accepted.

CVSS 4.0 · 6 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-6681

PKCS#7 decode ignores caller output buffer size, writing past buffer bounds

The PKCS#7 decode path ignores the caller-supplied output buffer size (outputSz), allowing decoded content to be written past the bounds of the provided buffer. This affects wolfSSL 5.9.0 and earlier and was fixed in the 5.9.1 release.

CVSS 4.0 · 1 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-6679

DTLS 1.3 ACK serialization heap buffer overflow via integer truncation

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.

CVSS 4.0 · 8.8 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-6678

Integer underflow in wc_PKCS7_DecryptOri handling crafted Other Recipient Info

Integer underflow in wc_PKCS7_DecryptOri when handling crafted Other Recipient Info, leading to incorrect length handling during decryption.

CVSS 4.0 · 1 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-6450

CRL critical extension bypass in ParseCRL_Extensions

A CRL critical extension bypass exists in ParseCRL_Extensions where critical extensions are not properly enforced, allowing a crafted CRL with an unhandled critical extension to be accepted. This only affects builds with CRL support enabled and where a crafted CRL had a trusted signature when parsed.

CVSS 4.0 · 1 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-6412

Continued acceptance of SHA-1/MD5 digests in certificate processing

Certificate policy and RFC 8446 compliance concerns regarding the continued acceptance of SHA-1/MD5 in certificate processing.

CVSS 4.0 · 2.3 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-7511

PKCS7_verify signer confusion allows forged signatures to be accepted

PKCS7_verify signer confusion allows forged signatures, where the signer associated with a signature is not correctly bound, permitting a forged signature to be accepted.

CVSS 4.0 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-7532

iPAddress name constraints not enforced when WOLFSSL_IP_ALT_NAME is undefined

iPAddress name constraints bypass when WOLFSSL_IP_ALT_NAME is not defined. IP address name constraints are not enforced in that configuration, allowing a certificate to bypass an issuing CA's IP address constraints.

CVSS 4.0 · 5.7 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-8720

HMAC-BLAKE2 final discards message when key length exceeds block size

wc_Blake2bHmacFinal and wc_Blake2sHmacFinal discard the message when the key length exceeds the block size, producing a MAC that is independent of the input. When the supplied key is longer than the BLAKE2 block size the key-hashing branch reinitialized the running hash state, discarding the accumulated message data, so the resulting MAC depended only on the key and not on the message being authenticated. This bug is specific to the HMAC-BLAKE2 APIs that were added in wolfSSL version 5.9.0.

CVSS 4.0 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-10098

OCSP CertID serial-number length-confusion in wolfSSL_OCSP_resp_find_status

OCSP CertID serial-number length-confusion in wolfSSL_OCSP_resp_find_status allows a same-issuer SingleResponse whose serial is a prefix of the target serial to be reported as the revocation status of a different certificate. The lookup compared serial-number bytes without first requiring the two serial numbers to be of equal length, so a SingleResponse for one certificate (same issuer) whose serial is a prefix of the target's serial would match, returning the wrong certificate's status. The fix requires the serial lengths to be equal before comparing the serial bytes.

CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Vendors
Products