EUVD-2026-21180
GHSA-vgv9-mv66-mpc7
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/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
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/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
Lifecycle Timeline
4DescriptionCVE.org
In wolfSSL, ARIA-GCM cipher suites used in TLS 1.2 and DTLS 1.2 reuse an identical 12-byte GCM nonce for every application-data record. Because wc_AriaEncrypt is stateless and passes the caller-supplied IV verbatim to the MagicCrypto SDK with no internal counter, and because the explicit IV is zero-initialized at session setup and never incremented in non-FIPS builds. This vulnerability affects wolfSSL builds configured with --enable-aria and the proprietary MagicCrypto SDK (a non-default, opt-in configuration required for Korean regulatory deployments). AES-GCM is not affected because wc_AesGcmEncrypt_ex maintains an internal invocation counter independently of the call-site guard.
AnalysisAI
wolfSSL's ARIA-GCM cipher suites in TLS 1.2 and DTLS 1.2 reuse an identical 12-byte nonce for every encrypted application-data record, enabling plaintext recovery through cryptanalytic attacks. This vulnerability affects only non-FIPS builds explicitly configured with --enable-aria and the proprietary MagicCrypto SDK (opt-in for Korean regulatory compliance). Authenticated remote attackers can exploit this to recover encrypted data, though AES-GCM implementations in the same product are unaffected due to independent invocation counters. No public exploit code or active exploitation has been identified at time of analysis.
Technical ContextAI
GCM (Galois/Counter Mode) is a confidentiality and authenticity cipher mode that requires a unique nonce per encryption operation to prevent key-stream reuse attacks. wolfSSL's ARIA-GCM implementation in TLS/DTLS delegates encryption to the external MagicCrypto SDK through the stateless wc_AriaEncrypt function, which passes the caller-supplied IV directly without maintaining an internal counter. The explicit IV (used in TLS record layer) is initialized to zero at session setup and never incremented in non-FIPS builds, causing all subsequent records to encrypt under the same nonce. This violates GCM security requirements and allows attackers to identify XOR differences between ciphertexts encrypted under identical nonces, facilitating plaintext recovery via algebraic attacks. The root cause is classified as CWE-323 (Uninitialized Variable), reflecting the zero-initialized IV that remains static. By contrast, wolfSSL's AES-GCM implementation (wc_AesGcmEncrypt_ex) maintains an independent invocation counter, preventing nonce reuse even when called with identical external IVs.
RemediationAI
Apply the upstream fix from wolfSSL GitHub pull request #10111 (https://github.com/wolfSSL/wolfssl/pull/10111), which corrects the nonce-reuse behavior in ARIA-GCM implementations. Exact patched version numbers are not confirmed in provided data; consult the official wolfSSL release notes following PR merge. Immediate mitigation without patching: disable ARIA-GCM cipher suites in TLS configuration and switch to AES-GCM (which is not affected) or other non-ARIA alternatives. If ARIA compliance is required, verify whether FIPS-mode builds are mandated for your regulatory context, as the vulnerability appears isolated to non-FIPS configurations. For deployments integrating the MagicCrypto SDK, coordinate with Korean regulatory authorities or wolfSSL support to confirm whether alternative ARIA implementations (non-MagicCrypto) are acceptable.
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 weakness CWE-323 – Reusing a Nonce, Key Pair in Encryption
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today