wolfSSL CVE-2026-6331

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.

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.

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.