EUVD-2026-21234
GHSA-65xm-pfx9-g5p3
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/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
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/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
Lifecycle Timeline
3DescriptionCVE.org
In TLSX_EchChangeSNI, the ctx->extensions branch set extensions unconditionally even when TLSX_Find returned NULL. This caused TLSX_UseSNI to attach the attacker-controlled publicName to the shared WOLFSSL_CTX when no inner SNI was configured. TLSX_EchRestoreSNI then failed to clean it up because its removal was gated on serverNameX != NULL. The inner ClientHello was sized before the pollution but written after it, causing TLSX_SNI_Write to memcpy 255 bytes past the allocation boundary.
AnalysisAI
Buffer overflow in WolfSSL's TLSX_SNI_Write function allows remote unauthenticated attackers to corrupt memory by sending a specially crafted TLS ClientHello with ECH (Encrypted Client Hello) and SNI extension data. The vulnerability occurs when TLSX_EchChangeSNI unconditionally sets extensions even when no inner SNI is configured, causing attacker-controlled SNI data to be written 255 bytes beyond the allocated buffer boundary during ClientHello serialization. CVSS 6.9 indicates moderate integrity and availability impact with low attack complexity.
Technical ContextAI
WolfSSL is a TLS/SSL library implementation written in C, commonly embedded in IoT devices, constrained systems, and security appliances. The vulnerability resides in the ECH (Encrypted Client Hello) extension handling during TLS 1.3 handshakes. The root cause is a CWE-787 (Out-of-bounds Write) bug in the SNI extension processing pipeline: TLSX_EchChangeSNI fails to validate whether TLSX_Find returns NULL before unconditionally assigning extensions, allowing attacker-controlled publicName to pollute the shared WOLFSSL_CTX structure. TLSX_EchRestoreSNI's cleanup routine is then bypassed because its NULL check on serverNameX prevents removal of the corrupted state. When TLSX_SNI_Write subsequently serializes the inner ClientHello, it copies SNI data that was sized before the pollution but written after it, resulting in a 255-byte memcpy operation that overflows the allocated buffer. This is a classic time-of-check-time-of-use (TOCTOU) variant where state validation and buffer usage are separated, allowing an attacker to modify shared state between these operations.
RemediationAI
Update WolfSSL to a version that includes the fix from PR #10102 (https://github.com/wolfSSL/wolfssl/pull/10102). The specific patched version number is not provided in available data; users must verify against the WolfSSL GitHub releases or contact the vendor (facts@wolfssl.com) for the exact release version incorporating this fix. The patch corrects TLSX_EchChangeSNI to validate that TLSX_Find returns a non-NULL value before unconditionally setting extensions, and ensures TLSX_EchRestoreSNI properly cleans up polluted SNI state regardless of inner SNI configuration. For systems unable to patch immediately, mitigation strategies include disabling ECH extension support in WolfSSL configuration if not required for functionality, or restricting TLS connections to trusted clients only if feasible. Recompile WolfSSL from source with the patched code and redeploy to all affected systems, particularly network-facing TLS servers and VPN endpoints.
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-787 – Out-of-bounds Write
View allSame technique Memory Corruption
View allShare
External POC / Exploit Code
Leaving vuln.today