CVE-2026-106465 in NetX Duo
Summary
by MITRE • 10/14/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability resides within the NetX Secure DTLS implementation, specifically affecting the handling of the HelloVerifyRequest mechanism during the initial handshake phase. Datagram Transport Layer Security (DTLS) relies on a cookie-based verification process to mitigate denial-of-service attacks by ensuring that clients possess return routability and can respond to packets sent from their claimed source IP address. In this flawed implementation, the server correctly generates and transmits a HelloVerifyRequest containing a freshly generated cryptographic cookie to the client. However, the critical failure occurs during the subsequent ClientHello processing stage where the server fails to validate the integrity or authenticity of the returned cookie against the one it originally issued.
The technical root cause is a logic error in the ClientHello parser which blindly copies the client-supplied cookie bytes over the expected value without performing any cryptographic verification. Instead of comparing the received cookie with the generated secret, the server determines whether the client has been verified solely based on the length of the provided cookie data. This design flaw means that if an attacker includes even a single byte in their initial ClientHello message, the server interprets this as successful verification and proceeds to complete the handshake. Consequently, the fundamental security guarantee of return-routability is entirely bypassed, allowing any peer to establish a secure session regardless of whether they actually control the source IP address claimed in the packet headers.
The operational impact of this vulnerability is severe, particularly for services that rely on DTLS for authentication and data integrity over UDP. Attackers can exploit this flaw to perform spoofing attacks by forging source addresses while successfully completing the handshake process. This enables a range of malicious activities including amplification-based denial-of-service attacks where the victim's IP address is used to generate traffic, resource exhaustion through the creation of numerous fake sessions that consume server memory and processing power, and potential bypasses for access controls that depend on DTLS session establishment. Since the server accepts connections from forged addresses without verification, it becomes trivial for an adversary to hide their true identity or launch distributed attacks with impunity.
This vulnerability aligns with CWE-287 Improper Authentication as the system fails to correctly verify the client's identity through proper cryptographic validation of the handshake parameters. It also relates to CWE-345 Insufficient Verification of Data Authenticity because the server accepts data that has not been validated against a trusted source value. From an offensive security perspective, this flaw maps directly to MITRE ATT&CK technique T1498 Network Denial of Service specifically under subtechnique 1498.003 Reflection Amplification Attack, as it facilitates the use of vulnerable servers in reflection-based DoS campaigns by allowing attackers to spoof source addresses and force the server to engage with unverified peers.
Mitigation strategies must focus on correcting the handshake validation logic within the DTLS stack. The implementation should be updated to strictly compare the cookie received from the client against the one generated during the HelloVerifyRequest phase using a secure comparison method that prevents timing attacks. If the cookies do not match exactly, or if no valid cookie is present in the first ClientHello where required by protocol specifications for unverified clients, the server must reject the connection attempt and discard the packet without proceeding to key exchange or session establishment. Additionally, implementing rate limiting on new connections from single source IPs can provide a secondary layer of defense against automated exploitation attempts while patches are deployed.