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
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
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | All of the following conditions must be simultaneously true for exploitation: (1) wolfSSL must be compiled for and executing on ARM64 hardware with NEON intrinsic support; (2) ML-KEM must be compiled in via WOLFSSL_HAVE_MLKEM and WOLFSSL_WC_MLKEM and actively used for key encapsulation/decapsulation; (3) for FIPS builds, the FIPS version must be 7.0.0 or later, as pre-7.0.0 FIPS builds are excluded from the affected code path per the PR test guard; (4) the attacker must be able to submit adaptively chosen ciphertexts to the decapsulating endpoint - requiring at minimum a man-in-the-middle network position or control over the ciphertext input channel. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 4.0 score of 6.3 with AV:N/AC:H/AT:P reflects meaningful real-world friction that limits the at-risk population: the vulnerable code path requires ARM64 hardware with NEON support, ML-KEM explicitly compiled in (WOLFSSL_HAVE_MLKEM/WOLFSSL_WC_MLKEM), and an attacker with the ability to submit adaptive ciphertext queries to the decapsulating party. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker with a man-in-the-middle position on a post-quantum TLS 1.3 session between a client and an ARM64 wolfSSL server with ML-KEM enabled intercepts the ML-KEM ciphertext in transit and modifies bytes in the second half (the unchecked region), then forwards the tampered ciphertext to the server. The server's ARM64 NEON comparison passes despite the modification, implicit rejection does not fire, and the server derives and uses a shared secret from the attacker-influenced input. … |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
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