EUVD-2026-39570
GHSA-89v8-3927-wfcg
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/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 because ciphertexts are submitted over the network; AC:H for ARM64 NEON plus ML-KEM prerequisites; C:H because adaptive attack enables shared-secret recovery; I:L for attacker-influenced key material weakening session integrity.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
2DescriptionCVE.org
The ML-KEM ARM64 NEON ciphertext comparison only compares half of the input, breaking the Fujisaki-Okamoto transform's implicit rejection and weakening IND-CCA2 security on that code path. The constant-time comparison effectively ignored part of the re-encrypted ciphertext, so a decapsulating party could fail to detect a manipulated ciphertext and proceed without the standard's required implicit rejection.
AnalysisAI
wolfSSL's ML-KEM ARM64 NEON decapsulation path compares only half of the re-encrypted ciphertext during the Fujisaki-Okamoto implicit rejection step, breaking the IND-CCA2 security proof for post-quantum key exchange on that architecture. This affects any ARM64 deployment of wolfSSL with ML-KEM (FIPS 203) compiled in and in active use. An attacker who can submit adaptively chosen ciphertexts to a decapsulating party - for example via man-in-the-middle position during a post-quantum TLS handshake - may exploit the broken comparison to bypass implicit rejection, potentially enabling shared-secret recovery through repeated adaptive queries. No public exploit has been identified and the vulnerability is not listed in the CISA KEV at time of analysis.
Technical ContextAI
ML-KEM (Module Lattice Key Encapsulation Mechanism, NIST FIPS 203) achieves IND-CCA2 security through the Fujisaki-Okamoto (FO) transform: during decapsulation the implementation must re-encrypt the recovered plaintext and compare the resulting ciphertext byte-for-byte against the original input, returning a pseudo-random value (implicit rejection) if any discrepancy is found. In wolfSSL (cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*), the ARM64 NEON-optimized constant-time comparison routine processed only half of the ciphertext bytes, so the second half of the ciphertext was effectively unchecked. CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) captures the root cause: the defective comparison invalidates the FO transform's security reduction, meaning the scheme no longer provably resists chosen-ciphertext attacks. The defect is architecture-specific and only present in builds compiled for ARM64 with NEON intrinsics; x86-64 and other architecture builds follow a different comparison path and are unaffected. The PR diff confirms regression tests were added to verify implicit rejection fires at byte offsets 0 and 32 of ML-KEM ciphertexts.
RemediationAI
The upstream fix is available as GitHub PR #10192 (https://github.com/wolfSSL/wolfssl/pull/10192), which corrects the half-comparison defect and adds regression tests covering ciphertext tampering at byte offsets 0 and 32. However, a tagged release version incorporating this fix has not been independently confirmed from available data - the fix exists as a pull request commit, not a versioned release; organizations should monitor https://www.wolfssl.com/docs/security-vulnerabilities/ for an official patched release announcement before declaring remediation complete. As an immediate compensating control, disabling ML-KEM at compile time by removing WOLFSSL_HAVE_MLKEM and WOLFSSL_WC_MLKEM eliminates the vulnerable code path entirely, at the cost of losing post-quantum key exchange capability. Where ML-KEM cannot be disabled, restricting deployments to non-ARM64 builds (e.g., x86-64) bypasses the NEON-specific comparison defect without sacrificing post-quantum support, but requires a recompilation and redeployment cycle. Applications operating ML-KEM decapsulation on ARM64 over untrusted networks should treat this as a priority until a verified patched release is available.
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