Eclipse NetX Duo CVE-2026-106465

Exploitation requires the target to be running NetX Secure in DTLS server mode performing the HelloVerifyRequest cookie exchange - i.e. a reachable DTLS listener - and succeeds against default configurations because the cookie-validation defect is in the standard handshake path, needing no authentication (PR:N) and no user interaction (UI:N). The practical limiting factors are network reachability of the DTLS server endpoint and that the realized harm is anti-spoofing/availability abuse (forged-source handshakes, amplification, resource exhaustion) rather than data compromise; devices not exposing a DTLS server, or fronted by stateful filtering that enforces return-routability, are not exploitable.

This is a genuine integrity/availability concern in the DTLS handshake rather than a code-execution flaw, and the supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms remote, unauthenticated, low-complexity reachability with no user interaction, scoring 8.7 (High). Impact is isolated to availability - VA:H (vulnerable system) and SA:L (subsequent system) with VC/VI/VA integrity and confidentiality set to N - consistent with the root cause: the server never validates the returned DTLS cookie, defeating the return-routability check that normally prevents spoofed-source handshakes and amplification/reflection abuse. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the real-world urgency therefore rests on exposure (internet-facing DTLS servers) rather than on observed in-the-wild activity. The CVSS network vector is consistent with the description, so no attack-vector conflict exists; the main caveat is that this is a defense-in-depth/anti-spoofing control failure whose practical harm (DoS amplification, resource exhaustion from forged clients) depends on deployment, not a direct compromise of the device's data.

An attacker on the network sends a DTLS ClientHello to an exposed NetX Secure DTLS server with any single arbitrary byte placed in the cookie field of the first ClientHello. Because the server judges verification solely from the cookie length and never checks the value it issued, it skips the HelloVerifyRequest return-routability exchange and completes handshakes for forged (spoofed) source addresses, enabling spoofed-source handshakes and amplification/reflection toward third parties. No public exploit is identified at time of analysis, but the condition is trivial to trigger given the network/low-complexity vector.