Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify wolfSSL OPENSSL_EXTRA deployment
-
DeliveryLocate HMAC-verified message/token endpoint
-
ExploitCraft message with zero-length HMAC tag
-
ExecutionSubmit to EVP_DigestVerifyFinal
-
PersistBypass integrity check
-
ImpactForge authenticated message
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
|
| Exploitation Conditions | The target application must be compiled against wolfSSL with the OPENSSL_EXTRA build-time flag explicitly set, and must not have NO_HMAC or NO_SHA256 disabled. The application must use the OpenSSL-compatible EVP_DigestVerifyFinal function with an EVP_PKEY_HMAC key type for authentication. The attacker must be able to supply or influence the tag buffer and its length argument passed to EVP_DigestVerifyFinal - for example, by controlling the signature portion of a JWT, a signed API request, or another authenticated message format. The CVSS 4.0 vector (AV:L/AC:H/AT:P) indicates local access and high attack complexity with prerequisites in the official scoring, likely reflecting embedded/IoT deployment models; however, network-accessible services that use wolfSSL for token verification extend the effective attack surface to network-reachable adversaries. Exploitation is limited to builds explicitly compiled with OPENSSL_EXTRA - the default wolfSSL build without this flag is not affected. |
| Impact | The official CVSS 4.0 vector scores this at 2.1 (Low): AV:L/AC:H/AT:P/PR:N/UI:N with integrity-only impact (VI:L). The local attack vector and high complexity reflect that exploitation depends on build-time prerequisites (OPENSSL_EXTRA enabled) and application-level conditions (the attacker must be able to supply the tag length argument). No KEV listing and no public exploit code are present in the input data, and no EPSS score was provided. Despite the low official severity, the practical impact is context-dependent: in network-facing applications such as JWT verification services or API authentication middleware built on wolfSSL with OPENSSL_EXTRA, the attack vector effectively becomes network-reachable if the attacker controls the authentication token. The CVSS 4.0 score of 2.1 is defensible for the embedded/IoT use case where local access dominates, but may understate risk for web-service deployments. The integrity-only impact (VI:L, no confidentiality or availability) is consistent with signature bypass: an attacker can forge authentication but cannot read encrypted data or crash the system through this flaw alone. The "JWT Attack" tag in the intelligence data is a meaningful signal that real-world exploitation paths exist in token-based authentication systems, which warrants higher priority for wolfSSL deployments in those contexts. |
| Exploit ScenarioDerived | An attacker targeting a network-accessible service that uses wolfSSL with OPENSSL_EXTRA for JWT or HMAC-based message authentication submits a crafted token or message with a zero-length or empty HMAC signature field. The vulnerable EVP_DigestVerifyFinal code path accepts the zero-length tag as valid because the length check does not require equality with the full MAC size, causing the application to treat the unauthenticated message as legitimately signed. No public exploit code has been identified at time of analysis, but the attack is mechanically straightforward for any developer familiar with the OpenSSL EVP API. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 25, 2026
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.
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).
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when OpenSSL gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
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
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
DescriptionCVE.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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Rated cri
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
In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehas
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
EUVD-2026-39565
GHSA-5hpf-pc4x-3jcf
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB