EUVD-2026-39579
GHSA-34qm-63x6-fcm3
Severity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/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:L per vendor assessment; AC:H because key must strictly exceed block size (maps from CVSS 4.0 AT:P); I:H for complete MAC forgery; no confidentiality or availability impact.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
2DescriptionCVE.org
wc_Blake2bHmacFinal and wc_Blake2sHmacFinal discard the message when the key length exceeds the block size, producing a MAC that is independent of the input. When the supplied key is longer than the BLAKE2 block size the key-hashing branch reinitialized the running hash state, discarding the accumulated message data, so the resulting MAC depended only on the key and not on the message being authenticated. This bug is specific to the HMAC-BLAKE2 APIs that were added in wolfSSL version 5.9.0.
AnalysisAI
MAC forgery in wolfSSL 5.9.0 and later allows an attacker to authenticate arbitrary tampered messages when HMAC-BLAKE2 is used with keys exceeding the BLAKE2 block size. The wc_Blake2bHmacFinal and wc_Blake2sHmacFinal functions incorrectly reused the running message hash state to process oversized keys, discarding accumulated message data and producing a MAC that depends solely on the key, not the message. No public exploit has been identified at time of analysis, but the integrity failure is straightforward to exploit in any protocol or application that uses wolfSSL HMAC-BLAKE2 with keys longer than 128 bytes (BLAKE2b) or 64 bytes (BLAKE2s).
Technical ContextAI
BLAKE2 is a cryptographic hash function standardized in RFC 7693, supporting two variants: BLAKE2b (128-byte block size, 64-byte output) and BLAKE2s (64-byte block size, 32-byte output). wolfSSL (cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*) added HMAC-BLAKE2 APIs in version 5.9.0 as wc_Blake2bHmacInit/Final and wc_Blake2sHmacInit/Final. The HMAC construction requires that keys exceeding the hash block size be pre-hashed before use. The bug (CWE-354: Improper Validation of Integrity Check Value) manifests in the HmacFinal functions, which reused the same Blake2b or Blake2s state object already holding accumulated message data to perform the key-hashing step. This reinitializes the same state, destroying all buffered message content, so the resulting MAC is computed over an empty message concatenated with the padded key hash rather than the actual input. The PR #10447 fix introduces a separate keyHash local variable for key pre-hashing, adds ForceZero to securely clear temporary key material, and includes regression tests with long-key vectors to prevent recurrence.
RemediationAI
Apply the fix from GitHub PR #10447 (https://github.com/wolfSSL/wolfssl/pull/10447) once a tagged wolfSSL release incorporating it is published; monitor https://www.wolfssl.com/docs/security-vulnerabilities/ for the confirmed release version. No specific patched version number was independently confirmed in the available data, so do not upgrade to an unverified build. As an immediate compensating control, audit all calls to wc_Blake2bHmacFinal and wc_Blake2sHmacFinal and enforce that supplied keys are at most 128 bytes for BLAKE2b or 64 bytes for BLAKE2s - keys at or below the block size do not trigger the bug, though this may require protocol changes if key derivation produces longer outputs. Alternatively, migrate authentication-critical code paths from HMAC-BLAKE2 to HMAC-SHA256 or HMAC-SHA3, noting that doing so may require interoperability coordination with remote peers. Applications using wolfSSL's pre-existing HMAC-SHA or HMAC-SHA3 APIs are unaffected by this specific flaw.
wolfSSL prior to version 3.12.2 provides a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange i
A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting
wolfSSL (formerly CyaSSL) before 3.6.8 allows remote attackers to cause a denial of service (resource consumption or tra
In wolfSSL before 5.5.1, malicious clients can cause a buffer overflow during a TLS 1.3 handshake. Rated high severity (
An issue was discovered in wolfSSL before 5.5.0. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
wolfSSL 4.3.0 has mulmod code in wc_ecc_mulmod_ex in ecc.c that does not properly resist timing side-channel attacks. Ra
In wolfSSL 4.1.0 through 4.2.0c, there are missing sanity checks of memory accesses in parsing ASN.1 certificate data wh
An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Rated high severity (CVSS 7.0).
wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in t
wolfSSL (formerly CyaSSL) before 3.6.8 does not properly handle faults associated with the Chinese Remainder Theorem (CR
An issue was discovered in wolfSSL before 5.5.0 (when --enable-session-ticket is used); however, only version 5.3.0 is e
wolfSSL 4.6.x through 4.7.x before 4.8.0 does not produce a failure outcome when the serial number in an OCSP request di
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today