Wolfssl Inc. vulnerabilities

12 vulnerabilities

Known vulnerabilities in Wolfssl Inc. products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 6 products.

Products

6
RoutineCVE-2026-84897wolfssl inc. · wolfssh +2 morewolfSSH server accepts server-to-client DH group exchange messages from an unauthenticated client, causing pre-authentication primality-test CPU exhaustion and key exchange role confusionsrc/internal.c in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange messages SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33) when a server receives them from an unauthenticated client. IsMessageAllowedServer() applies no direction check to the key exchange message range: when the peer is keying and no particular message is expected, which is the state a server is in for the whole window after it processes the client's KEXINIT because nothing sets handshake->expectMsgId there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that admits every message id from 30 through 34. A client that negotiates diffie-hellman-group-exchange-sha256 and then sends message 31 makes the server run the client-side handler DoKexDhGexGroup(), which validates the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on p and one on (p-1)/2, on a value of up to 8192 bits. The handler then returns success: the server stores the attacker's prime and generator, generates a Diffie-Hellman key pair in the attacker's group, and sends the client-role message SSH_MSG_KEX_DH_GEX_INIT (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public key check callback is registered, so it carries no comparable cost. Builds that define WOLFSSH_NO_DH_GEX_SHA256, which is implied by WOLFSSH_NO_DH or NO_SHA256, are unaffected.CVSS6.9MediumEPSS0.48%RoutineCVE-2026-83742wolfssl inc. · wolfssh +2 morewstrncat() unsigned integer underflow leads to an off-by-one null write in wolfSSH on non-Windows platformsUnsigned integer underflow in wstrncat() in src/port.c in wolfSSL wolfSSH from v1.4.11 through v1.5.0 on non-Windows platforms allows an authenticated remote attacker to write one out-of-bounds null byte past the end of a stack buffer by sending a crafted SFTP path. wolfSSH_RealPath() in src/ssh.c appends each path component with a remaining-size bound (outSz - curSz) rather than the full destination size, so once the accumulated path reaches half the output buffer the size_t computation n - strlen(s1) - 1 wraps to near SIZE_MAX. The strncat() call is then effectively unbounded and copies the whole component; when that component exactly fills the remainder of the buffer, its terminating null is written one byte past the end. The caller's own length check keeps the copied data inside the buffer, so the overflow is limited to that single null byte, which may corrupt an adjacent stack value and crash the process. Applications that call the public wolfSSH_RealPath() with an output buffer smaller than the input path are additionally exposed to an unbounded copy, because the word32 expression outSz - segSz in that length check also wraps.CVSS8.8HighEPSS0.43%RoutineCVE-2026-81535wolfssl inc. · wolfssh +2 morewolfSSH SSH client accepts unsolicited forwarded-tcpip channel opens without an authorization checkIn wolfSSH through 1.5.0 built with --enable-fwd, DoChannelOpen() in src/internal.c gates only direct-tcpip channel opens with the forwarding policy callback. forwarded-tcpip opens are admitted without an authorization check and are not capped in number, allowing a malicious SSH peer to make an endpoint allocate unbounded per-channel buffers for forwarding channels the application never authorized. A client also does not check a forwarded-tcpip open against the forwards it registered with a tcpip-forward request, as RFC 4254 section 7.2 requires, so a malicious server can open forwarding channels for addresses and ports the client never asked it to forward.CVSS9.1CriticalEPSS0.30%PrioritiseCVE-2026-16516wolfssl inc. · wolfssh +2 morewolfSSH ECDSA host key curve not validated against negotiated algorithmwolfSSH does not validate that the ECDSA curve identifier in a KEXDH_REPLY host key blob matches the algorithm negotiated during key exchange. In ParseECCPubKey() (src/internal.c), the blob's algorithm string is used to derive the curve via NameToId/wcPrimeForId without checking against the negotiated ssh->handshake->pubKeyId, and the RFC 5656 curve identifier string is discarded via GetSkip() rather than compared. An active network man-in-the-middle attacker can substitute a host key blob containing a different ECDSA curve, causing the client to import the key on the wrong curve. Because the attacker controls the private key for the substituted curve, signature verification passes. Exploitation requires an active MitM position and a lax public key check callback (e.g., TOFU, algorithm-name-only check, or fingerprint match against the parsed key).CVSS9.0CriticalEPSS0.19%RoutineCVE-2026-81341wolfssl inc. · wolfengine +1 morewolfEngine reuses the AES-CCM nonce on TLS 1.2 / DTLS 1.2 recordswolfEngine before 1.4.1 sources the explicit AES-CCM nonce for TLS 1.2 and DTLS 1.2 records from the record input buffer instead of the TLS sequence number carried in the additional authenticated data. Because the record layer leaves the explicit-nonce field for the cipher to populate, the value read is constant across records, so every AES-CCM record within a connection is encrypted under an identical key and nonce pair. Reusing a CCM key and nonce weakens confidentiality (identical keystream across records, so a known record recovers the others) and integrity (authentication tag forgery). Only wolfEngine is affected; wolfProvider is not. AES-GCM under wolfEngine is tracked separately. AES-CCM cipher suites are not enabled by default and must be explicitly selected, which limits exposure. TLS 1.3 and non-TLS use of the cipher are not affected.CVSS6.5MediumEPSS0.32%PrioritiseCVE-2026-81020wolfssl inc. · wolfengine +1 morewolfEngine reuses the AES-GCM nonce on every TLS 1.2 / DTLS 1.2 recordwolfEngine before 1.4.1 generates the 8-byte explicit AES-GCM nonce once when the TLS write key is set and never increments it per record. As a result every TLS 1.2 and DTLS 1.2 AES-GCM record within a connection is encrypted under an identical key and nonce pair. Reusing a GCM key and nonce discloses the keystream (the XOR of two ciphertexts equals the XOR of their plaintexts, so one known record recovers the others) and leaks the GHASH authentication key, enabling authentication tag forgery. AES-CCM, TLS 1.3, and non-TLS use of the cipher are not affected.CVSS7.4HighEPSS0.38%PrioritiseCVE-2026-81019wolfssl inc. · wolfprovider +1 morewolfProvider reuses the AES-GCM nonce on every TLS 1.2 / DTLS 1.2 recordwolfProvider before 1.2.2 generates the 8-byte explicit AES-GCM nonce once when the TLS write key is set and never increments it per record. As a result every TLS 1.2 and DTLS 1.2 AES-GCM record within a connection is encrypted under an identical key and nonce pair. Reusing a GCM key and nonce discloses the keystream (the XOR of two ciphertexts equals the XOR of their plaintexts, so one known record recovers the others) and leaks the GHASH authentication key, enabling authentication tag forgery. AES-CCM, TLS 1.3, and non-TLS use of the cipher are not affected.CVSS7.4HighEPSS0.38%RoutineCVE-2026-3849wolfssl inc. · wolfssl +4 moreBuffer Overflow in HPKE via Oversized ECH ConfigStack Buffer Overflow in wc_HpkeLabeledExtract via Oversized ECH Config. A vulnerability existed in wolfSSL 5.8.4 ECH (Encrypted Client Hello) support, where a maliciously crafted ECH config could cause a stack buffer overflow on the client side, leading to potential remote execution and client program crash. This could be exploited by a malicious TLS server supporting ECH. Note that ECH is off by default, and is only enabled with enable-ech.CVSS9.8CriticalEPSS0.45%RoutineCVE-2026-3503wolfssl inc. · wolfssl (wolfcrypt) +4 moreFault injection attack with ML-DSA and ML-KEM on ARMProtection mechanism failure in wolfCrypt post-quantum implementations (ML-KEM and ML-DSA) in wolfSSL on ARM Cortex-M microcontrollers allows a physical attacker to compromise key material and/or cryptographic outcomes via induced transient faults that corrupt or redirect seed/pointer values during Keccak-based expansion. This issue affects wolfSSL (wolfCrypt): commit hash d86575c766e6e67ef93545fa69c04d6eb49400c6.CVSS5.2MediumEPSS0.16%RoutineCVE-2025-7844wolfssl inc. · wolftpmwolfTPM library wrapper function `wolfTPM2_RsaKey_TpmToWolf` copies external data to a fixed-size stack buffer without length validation potentially causing stack-based buffer overflowExporting a TPM based RSA key larger than 2048 bits from the TPM could overrun a stack buffer if the default `MAX_RSA_KEY_BITS=2048` is used. If your TPM 2.0 module supports RSA key sizes larger than 2048 bit and your applications supports creating or importing an RSA private or public key larger than 2048 bits and your application calls `wolfTPM2_RsaKey_TpmToWolf` on that key, then a stack buffer could be overrun. If the `MAX_RSA_KEY_BITS` build-time macro is set correctly (RSA bits match what TPM hardware is capable of) for the hardware target, then a stack overrun is not possible.CVSS1.0LowEPSS0.16%RoutineCVE-2024-5288wolfssl inc. · wolfssl +3 moreSafe-error attack on TLS 1.3 ProtocolAn issue was discovered in wolfSSL before 5.7.0. A safe-error attack via Rowhammer, namely FAULT+PROBE, leads to ECDSA key disclosure. When WOLFSSL_CHECK_SIG_FAULTS is used in signing operations with private ECC keys, such as in server-side TLS connections, the connection is halted if any fault occurs. The success rate in a certain amount of connection requests can be processed via an advanced technique for ECDSA key recovery.CVSS5.9MediumEPSS0.42%PrioritiseCVE-2024-2873wolfssl inc. · wolfssh +1 moreUser authentication bypass in wolfSSH serverA 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.CVSS9.1CriticalEPSS0.62%