EUVD-2026-39552
GHSA-gjm7-vch5-hch8
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/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
Any unauthenticated network peer can initiate X25519 key exchange (PR:N); specific edge-case inputs required (AC:H); impact is wrong shared secret causing connection failure only (A:L), no key disclosure.
Primary rating from Vendor (wolfssl).
CVSS VectorVendor: wolfssl
Lifecycle Timeline
2DescriptionCVE.org
The X25519 x86_64 assembly implementation fails to clear the most significant bit during the final modular reduction, so the computed result may not be fully reduced modulo the field prime 2^255 - 19. This can leave the field element in a non-canonical form, producing an incorrect result from the scalar multiplication and potentially a wrong shared secret. The final carry-propagation chains in the x64 and AVX2 reduction routines could overflow into the top bit, and the high limb was not masked afterward, so the 255-bit field element was left non-canonical.
AnalysisAI
wolfSSL's x86_64 Curve25519 scalar multiplication yields a non-canonical shared secret when carry propagation overflows into bit 255 during final modular reduction, producing a result in [p, 2^255) rather than the required canonical range [0, p). Both the x64 and AVX2 hand-written assembly paths in fe_x25519_asm.S are affected, and only specific edge-case scalar/point combinations trigger the flaw. wolfSSL self-reported this correctness defect and published a fix via GitHub PR #10536; no public exploit exists and the vulnerability is absent from CISA KEV.
Technical ContextAI
X25519 (RFC 7748) performs scalar multiplication in the prime field GF(2^255−19). After the main field multiplication and carry propagation, the result must be fully reduced so every field element lies in [0, p). wolfSSL's x86_64 assembly file wolfcrypt/src/fe_x25519_asm.S implements four code paths - base x64, x64, base AVX2, and AVX2 - each containing a final carry-propagation chain. A residual carry from that chain could propagate into the top limb registers (%r10, %r11, %r11, %r12), setting bit 255 and leaving the 255-bit field element non-canonical. The required masking AND instruction was absent at all four sites. CWE-682 (Incorrect Calculation) correctly characterizes the root cause: the arithmetic is performed but the result is not normalized to the canonical field-element representation, violating the invariant expected by callers. The 'Buffer Overflow' NVD tag is a mis-categorization - this flaw is a missing bitwise mask, not a memory overread or overwrite.
RemediationAI
Apply the patch from GitHub PR #10536 (https://github.com/wolfSSL/wolfssl/pull/10536), which adds four andq masking instructions in fe_x25519_asm.S to clear the overflow bit after the final carry propagation in the base x64, x64, base AVX2, and AVX2 reduction routines. The specific patched tagged release version is not yet confirmed in the available data; monitor https://www.wolfssl.com/docs/security-vulnerabilities/ and the wolfSSL GitHub releases page for a formal version announcement before deploying. As a compensating control where assembly acceleration can be toggled at build time, recompiling wolfSSL without x86_64 Curve25519 assembly (falling back to the portable C field arithmetic implementation) eliminates the affected code paths entirely, at the cost of reduced Curve25519 throughput on x86_64 hosts. Organizations should confirm whether their wolfSSL build enables HAVE_CURVE25519 and assembly-optimized field arithmetic, as builds without those features are not affected.
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-682 – Incorrect Calculation
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today