CVE-2026-106465
8.7HighPublished 14 Oct 2026 · NVD status: Awaiting Analysis · AI triage by gemini-3.8-flash
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
- Impact
- High impact on availability
- Weakness
- CWE-290, CWE-406
Impact
Remote unauthenticated attackers can spoof source IP addresses to bypass DTLS cookie verification and establish handshakes, enabling resource exhaustion or amplification attacks. They only need network access to reach the listening DTLS service.
Root cause
The DTLS ClientHello parser overwrites the server-issued cookie with incoming client bytes and validates verification status solely based on cookie length rather than matching contents.
Affected systems
Eclipse ThreadX NetX Duo (NetX Secure DTLS server component); exact versions not listed — check the vendor advisory.
CVSS v4.0 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/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
Fix & remediation
Upgrade NetX Duo to the patched release referenced in advisory GHSA-7c5f-gmpm-f655 once available; as a temporary mitigation, restrict access to the DTLS port using upstream firewall rules or ACLs to trusted source IPs.
AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
The NetX Secure DTLS server sends a HelloVerifyRequest carrying a freshly generated cookie, but never checks the cookie a client returns. The ClientHello parser copies the client's cookie bytes over the value the server issued, and the server then decides whether the client has been verified from the cookie's length alone. A peer that puts any single cookie byte in its first ClientHello skips the verification exchange entirely, so the server has no return-routability check and completes handshakes for forged source addresses.