Wolfssl vulnerabilities, page 3
171 vulnerabilities
Known vulnerabilities in Wolfssl products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 8 products.
RoutineCVE-2026-55964wolfssl +3 moreChain intermediate CA:TRUE without keyCertSign accepted as a signing CA (temporary CA exemption)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.CVSS6.3MediumEPSS0.19%PrioritiseCVE-2026-11999wolfssl +3 moreX.509 trust-chain bypass via path-depth exhaustion in wolfSSL_X509_verify_cert()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: when the supplied chain is deeper than the verifier's maximum path depth (default 100), path building runs out of depth while still walking untrusted intermediates and the chain is accepted even though it never reaches a configured trust anchor, allowing acceptance of an attacker-controlled certificate. The default TLS handshake (WOLFSSL_VERIFY_PEER) is not affected; only applications doing manual or deferred verification through this API are.CVSS8.2HighEPSS0.23%RoutineCVE-2026-55967wolfssl +3 moreAES-GCM streaming APIs do not reject >64 GiB cumulative single messages, enabling counter wrap and keystream reuseAES-GCM encryption/decryption with extremely large cumulative single message sizes (>64 GiB) were not properly rejected by the streaming APIs, allowing counter wrap, keystream reuse, and consequent plaintext recovery.CVSS7.5HighEPSS0.18%PrioritiseCVE-2026-55961wolfssl +3 morewolfSSL_PKCS7_verify() reports success for degenerate (certs-only) PKCS#7 with no signerwolfSSL_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 signer certificate chain validation and was never intended to waive the requirement that a signature exist. Only affects OpenSSL compatibility builds that call the PKCS7_verify() compatibility API on potentially degenerate PKCS#7 bundles.CVSS8.2HighEPSS0.15%RoutineCVE-2026-6091wolfssl +3 morePartial-chain verification accepts untrusted intermediate as trust anchorPartial-chain certificate verification may accept chains that terminate at a peer-supplied, untrusted intermediate certificate rather than a trusted anchor. An attacker could present a chain that ends at an intermediate they control and have it accepted as valid. This affects the OpenSSL compatibility certificate-path-building path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the X509_V_FLAG_PARTIAL_CHAIN verify flag is enabled.CVSS6.5MediumEPSS0.19%RoutineCVE-2026-6291wolfssl +3 moreBleichenbacher padding oracle in PKCS#7 KTRI RSA PKCS#1 v1.5 decryptionAn attacker able to submit crafted EnvelopedData messages and observe error responses could use this as a padding oracle to incrementally recover the encrypted Content Encryption Key (CEK). The fix generates a deterministic pseudo-random fake CEK on padding failure (via HMAC-SHA256) and proceeds with decryption identically, using constant-time operations throughout, so that all failure paths produce the same error regardless of padding validity.CVSS6.5MediumEPSS0.24%RoutineCVE-2026-6094wolfssl +3 moreHeap buffer overread in wc_PKCS7_DecodeEnvelopedData parsing crafted PKCS7 EnvelopedDataThis could theoretically be triggered by attacker-supplied data delivered via S/MIME or CMS.CVSS9.1CriticalEPSS0.52%RoutineCVE-2026-0930wolfssl · wolfssh +1 morePotential wolfSSHd Buffer out-of-bounds Read on Windows Handling Terminal ResizePotential read out of bounds case with wolfSSHd on Windows while handling a terminal resize request. An authenticated user could trigger the out of bounds read after establishing a connection which would leak the adjacent stack memory to the pseudo-console output.CVSS4.3MediumEPSS0.17%PrioritiseCVE-2026-5477wolfssl +3 morePrefix-substitution forgery via integer overflow in wolfCrypt CMACAn 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 identical CMAC tags, enabling a zero-work prefix-substitution forgery. The fix removes the guard, making the XOR unconditional; the no-op property on the first block is preserved because digest is zero-initialized by wc_InitCmac_ex.CVSS8.2HighEPSS0.38%RoutineCVE-2026-5188wolfssl +3 moreInteger underflow in X.509 SAN parsing in wolfSSLAn integer underflow issue exists in wolfSSL when parsing the Subject Alternative Name (SAN) extension of X.509 certificates. A malformed certificate can specify an entry length larger than the enclosing sequence, causing the internal length counter to wrap during parsing. This results in incorrect handling of certificate data. The issue is limited to configurations using the original ASN.1 parsing implementation which is off by default.CVSS8.1HighEPSS0.14%PrioritiseCVE-2026-5500wolfssl +3 moreImproper Validation of AES-GCM Authentication Tag Length in PKCS#7 Envelope Allows Authentication BypasswolfSSL'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⁻⁸.CVSS8.7HighEPSS0.48%RoutineCVE-2026-5501wolfssl +3 moreImproper Certificate Signature Verification in X.509 Chain Validation Allows Forged Leaf CertificateswolfSSL_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_SUCCESS` / `X509_V_OK`. The native wolfSSL TLS handshake path (`ProcessPeerCerts`) is not susceptible and the issue is limited to applications using the OpenSSL compatibility API directly, which would include integrations of wolfSSL into nginx and haproxy.CVSS8.6HighEPSS0.32%RoutineCVE-2026-5466wolfssl +3 morewc_VerifyEccsiHash missing sanity checkwolfSSL's ECCSI signature verifier `wc_VerifyEccsiHash` decodes the `r` and `s` scalars from the signature blob via `mp_read_unsigned_bin` with no check that they lie in `[1, q-1]`. A crafted forged signature could verify against any message for any identity, using only publicly-known constants.CVSS8.1HighEPSS0.19%RoutineCVE-2026-5479wolfssl +3 morewolfSSL EVP ChaCha20-Poly1305 AEAD authentication tagIn wolfSSL's EVP layer, the ChaCha20-Poly1305 AEAD decryption path in wolfSSL_EVP_CipherFinal (and related EVP cipher finalization functions) fails to verify the authentication tag before returning plaintext to the caller. When an application uses the EVP API to perform ChaCha20-Poly1305 decryption, the implementation computes or accepts the tag but does not compare it against the expected value.CVSS8.1HighEPSS0.19%RoutineCVE-2026-5460wolfssl +3 moreHeap Use-After-Free in PQC Hybrid KeyShare Error Cleanup in wolfSSL TLS 1.3A heap use-after-free exists in wolfSSL's TLS 1.3 post-quantum cryptography (PQC) hybrid KeyShare processing. In the error handling path of TLSX_KeyShare_ProcessPqcHybridClient() in src/tls.c, the inner function TLSX_KeyShare_ProcessPqcClient_ex() frees a KyberKey object upon encountering an error. The caller then invokes TLSX_KeyShare_FreeAll(), which attempts to call ForceZero() on the already-freed KyberKey, resulting in writes of zero bytes over freed heap memory.CVSS6.5MediumEPSS0.21%RoutineCVE-2026-5448wolfssl +3 more1-2 Byte Buffer Overflow in wolfSSL_X509_notAfter/notBeforeX.509 date buffer overflow in wolfSSL_X509_notAfter / wolfSSL_X509_notBefore. A buffer overflow may occur when parsing date fields from a crafted X.509 certificate via the compatibility layer API. This is only triggered when calling these two APIs directly from an application, and does not affect TLS or certificate verify operations in wolfSSL.CVSS4.3MediumEPSS0.30%RoutineCVE-2026-5392wolfssl +3 morewolfSSL heap OOB read in PKCS7 SignedData streamingHeap out-of-bounds read in PKCS7 parsing. A crafted PKCS7 message can trigger an OOB read on the heap. The missing bounds check is in the indefinite-length end-of-content verification loop in PKCS7_VerifySignedData().CVSS5.4MediumEPSS0.16%RoutineCVE-2026-5393wolfssl +2 moreOOB Read in DoTls13CertificateVerify with WOLFSSL_DUAL_ALG_CERTSDual-Algorithm CertificateVerify out-of-bounds read. When processing a dual-algorithm CertificateVerify message, an out-of-bounds read can occur on crafted input. This can only occur when --enable-experimental and --enable-dual-alg-certs is used when building wolfSSL.CVSS9.1CriticalEPSS0.19%RoutineCVE-2026-5295wolfssl +3 moreStack Buffer Overflow in wolfSSL PKCS7 wc_PKCS7_DecryptOri() via Oversized OIDA stack buffer overflow exists in wolfSSL's PKCS7 implementation in the wc_PKCS7_DecryptOri() function in wolfcrypt/src/pkcs7.c. When processing a CMS EnvelopedData message containing an OtherRecipientInfo (ORI) recipient, the function copies an ASN.1-parsed OID into a fixed 32-byte stack buffer (oriOID[MAX_OID_SZ]) via XMEMCPY without first validating that the parsed OID length does not exceed MAX_OID_SZ. A crafted CMS EnvelopedData message with an ORI recipient containing an OID longer than 32 bytes triggers a stack buffer overflow. Exploitation requires the library to be built with --enable-pkcs7 (disabled by default) and the application to have registered an ORI decrypt callback via wc_PKCS7_SetOriDecryptCb().CVSS8.0HighEPSS0.18%RoutineCVE-2026-5503wolfssl +3 moreout-of-bounds write in TLSX_EchChangeSNI via attacker-controlled publicNameIn TLSX_EchChangeSNI, the ctx->extensions branch set extensions unconditionally even when TLSX_Find returned NULL. This caused TLSX_UseSNI to attach the attacker-controlled publicName to the shared WOLFSSL_CTX when no inner SNI was configured. TLSX_EchRestoreSNI then failed to clean it up because its removal was gated on serverNameX != NULL. The inner ClientHello was sized before the pollution but written after it, causing TLSX_SNI_Write to memcpy 255 bytes past the allocation boundary.CVSS9.1CriticalEPSS0.51%