Wolfssl vulnerabilities, page 5
171 vulnerabilities
Known vulnerabilities in Wolfssl products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 8 products.
PrioritiseCVE-2026-3548wolfssl +3 moreBuffer overflow in CRL number parsing in wolfSSLTwo buffer overflow vulnerabilities existed in the wolfSSL CRL parser when parsing CRL numbers: a heap-based buffer overflow could occur when improperly storing the CRL number as a hexadecimal string, and a stack-based overflow for sufficiently sized CRL numbers. With appropriately crafted CRLs, either of these out of bound writes could be triggered. Note this only affects builds that specifically enable CRL support, and the user would need to load a CRL from an untrusted source.CVSS9.8CriticalEPSS0.49%RoutineCVE-2026-2646wolfssl +3 moreHeap buffer overflow in session parsing with wolfSSL_d2i_SSL_SESSION() functionA heap-buffer-overflow vulnerability exists in wolfSSL's wolfSSL_d2i_SSL_SESSION() function. When deserializing session data with SESSION_CERTS enabled, certificate and session id lengths are read from an untrusted input without bounds validation, allowing an attacker to overflow fixed-size buffers and corrupt heap memory. A maliciously crafted session would need to be loaded from an external source to trigger this vulnerability. Internal sessions were not vulnerable.CVSS8.1HighEPSS0.13%RoutineCVE-2026-2645wolfssl +3 moreAcceptance of CertificateVerify Message before ClientKeyExchange in TLS 1.2In wolfSSL 5.8.2 and earlier, a logic flaw existed in the TLS 1.2 server state machine implementation. The server could incorrectly accept the CertificateVerify message before the ClientKeyExchange message had been received. This issue affects wolfSSL before 5.8.4 (wolfSSL 5.8.2 and earlier is vulnerable, 5.8.4 is not vulnerable). In 5.8.4 wolfSSL would detect the issue later in the handshake. 5.9.0 was further hardened to catch the issue earlier in the handshake.CVSS7.5HighEPSS0.13%RoutineCVE-2026-1005wolfssl +3 moreInteger underflow leads to out-of-bounds access in sniffer AES-GCM/CCM/ARIA-GCM decrypt pathInteger underflow in wolfSSL packet sniffer <= 5.8.4 allows an attacker to cause a buffer overflow in the AEAD decryption path by injecting a TLS record shorter than the explicit IV plus authentication tag into traffic inspected by ssl_DecodePacket. The underflow wraps a 16-bit length to a large value that is passed to AEAD decryption routines, causing heap buffer overflow and a crash. An unauthenticated attacker can trigger this remotely via malformed TLS Application Data records.CVSS5.3MediumEPSS0.26%RoutineCVE-2026-0819wolfssl +3 moreStack buffer overflow in PKCS7 SignedData encoding with custom signed attributesA stack buffer overflow vulnerability exists in wolfSSL's PKCS7 SignedData encoding functionality. In wc_PKCS7_BuildSignedAttributes(), when adding custom signed attributes, the code passes an incorrect capacity value (esd->signedAttribsCount) to EncodeAttributes() instead of the remaining available space in the fixed-size signedAttribs[7] array. When an application sets pkcs7->signedAttribsSz to a value greater than MAX_SIGNED_ATTRIBS_SZ (default 7) minus the number of default attributes already added, EncodeAttributes() writes beyond the array bounds, causing stack memory corruption. In WOLFSSL_SMALL_STACK builds, this becomes heap corruption. Exploitation requires an application that allows untrusted input to control the signedAttribs array size when calling wc_PKCS7_EncodeSignedData() or related signing functions.CVSS7.1HighEPSS0.10%PrioritiseCVE-2025-15346wolfssl · wolfssl-py +2 morewolfSSL Python library `CERT_REQUIRED` mode fails to enforce client certificate requirementA 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 mutual TLS (mTLS) client authentication by omitting a client certificate during the TLS handshake.
The issue affects versions up to and including 5.8.2.CVSS9.3CriticalEPSS0.33%RoutineCVE-2025-15382wolfssl · wolfssh +1 moreClient SCP Request Triggers Buffer Overread by 1 ByteA heap buffer over-read vulnerability exists in the wolfSSH_CleanPath() function in wolfSSH. An authenticated remote attacker can trigger the issue via crafted SCP path input containing '/./' sequences, resulting in a heap over read by 1 byte.CVSS8.1HighEPSS0.35%PrioritiseCVE-2025-14942wolfssl · wolfssh +1 moreAuthentication BypasswolfSSH’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, the same defect is present. Thanks to Aina Toky Rasoamanana of Valeo and Olivier Levillain of Telecom SudParis for the report.CVSS9.8CriticalEPSS0.39%RoutineCVE-2025-13912wolfssl +2 morePotential non-constant time compiled code with Clang LLVMMultiple constant-time implementations in wolfSSL before version 5.8.4 may be transformed into non-constant-time binary by LLVM optimizations, which can potentially result in observable timing discrepancies and lead to information disclosure through timing side-channel attacks.CVSS1.0LowEPSS0.15%RoutineCVE-2025-12889wolfssl +3 moreTLS 1.2 Client Can Downgrade Digest UsedWith TLS 1.2 connections a client can use any digest, specifically a weaker digest that is supported, rather than those in the CertificateRequest.CVSS5.4MediumEPSS0.14%RoutineCVE-2025-11932wolfssl +3 moreTiming Side-Channel in PSK Binder VerificationThe server previously verified the TLS 1.3 PSK binder using a non-constant time method which could potentially leak information about the PSK binderCVSS4.3MediumEPSS0.27%RoutineCVE-2025-11931wolfssl +3 moreInteger Underflow Leads to Out-of-Bounds Access in XChaCha20-Poly1305 DecryptThis 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.CVSS8.2HighEPSS0.34%RoutineCVE-2025-12888wolfssl +3 moreConstant Time Issue with Xtensa-based ESP32 and X22519Vulnerability 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.CVSS7.5HighEPSS0.31%RoutineCVE-2025-11936wolfssl +3 morePotential DoS Vulnerability through Multiple KeyShareEntry with Same Group in TLS 1.3 ClientHelloImproper 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.CVSS6.3MediumEPSS0.46%RoutineCVE-2025-11933wofssl · wolfssl +4 moreDoS Vulnerability in wolfSSL TLS 1.3 CKS ExtensionImproper 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.CVSS6.5MediumEPSS0.45%RoutineCVE-2025-11934wolfssl +3 moreImproper Validation of Signature Algorithm Used in TLS 1.3 CertificateVerifyImproper 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.CVSS2.7LowEPSS0.17%RoutineCVE-2025-11935wolfssl +3 moreForward Secrecy Violation in WolfSSL TLS 1.3With 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.CVSS7.5HighEPSS0.23%PrioritiseCVE-2025-11625wolfssl · wolfssh +1 moreHost verification bypass and credential leakImproper host authentication vulnerability in wolfSSH version 1.4.20 and earlier clients that allows authentication bypass and leaking of clients credentials.CVSS9.8CriticalEPSS0.43%RoutineCVE-2025-7396wolfssl +1 moreCurve25519 BlindingIn 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.CVSS5.6MediumEPSS0.22%RoutineCVE-2025-7394wolfssl +2 morewolfssl wolfsslIn 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.CVSS9.8CriticalEPSS0.46%