EUVD-2026-39565
GHSA-5hpf-pc4x-3jcf
Severity by source
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N reflects network-facing JWT and auth service use cases; AC:H captures OPENSSL_EXTRA build prerequisite; no confidentiality or availability impact.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
HMAC tag forgery in wolfSSL's OpenSSL-compatibility layer allows a zero-length or arbitrarily truncated HMAC tag to pass verification in EVP_DigestVerifyFinal, undermining message authentication for any application relying on this API path. Applications compiled with the OPENSSL_EXTRA flag that use EVP_DigestVerifyFinal for HMAC verification - including JWT validation libraries and message authentication flows - are affected across all currently-known wolfSSL versions. The root length check only enforced that the supplied tag did not exceed the MAC size, not that it equaled it, so an attacker controlling the tag buffer or length argument could present an empty signature and bypass integrity verification. No public exploit has been identified at time of analysis, and CISA KEV does not list this CVE.
Technical ContextAI
wolfSSL is an embedded-focused TLS/SSL library that provides an OpenSSL-compatible API surface, enabled at build time via the OPENSSL_EXTRA compile flag. The vulnerable code path is EVP_DigestVerifyFinal when used with an EVP_PKEY_HMAC key type - the OpenSSL-compatibility shim for HMAC signature verification. CWE-347 (Improper Verification of Cryptographic Signature) is the root cause: the length validation logic required only that siglen <= mac_len, not that siglen == mac_len. This means a caller supplying siglen=0 and any buffer would satisfy the check, causing the HMAC comparison to succeed over zero bytes - a trivially forgeable condition. The GitHub PR diff confirms the fix adds an explicit equality check (siglen must equal the full MAC output length) and a dedicated rejection path for zero-length inputs. The affected CPE is cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*, indicating all wolfSSL versions prior to the fix are potentially in scope. The test added in the PR (test_wolfSSL_EVP_DigestVerify_HMAC_zero_len_forgery) is conditioned on OPENSSL_EXTRA and !NO_HMAC and !NO_SHA256, confirming these are necessary build-time prerequisites.
RemediationAI
The upstream fix is available as GitHub PR #10192 at https://github.com/wolfSSL/wolfssl/pull/10192, which enforces strict tag-length equality in EVP_DigestVerifyFinal. Upstream fix available (PR/commit); released patched version not independently confirmed from available data - consult https://www.wolfssl.com/docs/security-vulnerabilities/ to identify the first tagged release containing this fix. As an interim workaround for applications that cannot immediately update, developers should validate that the supplied HMAC tag length exactly equals the expected MAC output length at the application layer before passing it to EVP_DigestVerifyFinal - this duplicates the missing library-level check. Alternatively, applications may switch to wolfSSL's native (non-OpenSSL-compatibility) HMAC API (wc_HmacVerify), which is not affected by this flaw. Disabling OPENSSL_EXTRA at build time eliminates the vulnerable code path entirely but also removes all OpenSSL-compatible EVP APIs, which may break dependent code. For JWT-issuing services, an additional defensive measure is to reject any incoming token whose signature field decodes to fewer bytes than the algorithm's expected output (e.g., reject signatures shorter than 32 bytes for HMAC-SHA256).
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not pro
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today