Eclipse NetX Duo EUVD-2026-89182

Requires a NetX Secure deployment acting as a DTLS server that issues HelloVerifyRequest cookies (the stateless DTLS anti-spoofing exchange, typically DTLS 1.0/1.2 servers). Exploitation is remote and unauthenticated (PR:N/UI:N) but limited by high attack complexity (AC:H): the attacker must predict or reconstruct the weakly-random cookie value, which depends on the strength and seeding of NetX Secure's cookie/RNG generation. It only matters where DTLS cookie exchange is relied upon for source-address validation/anti-amplification; TLS-over-TCP paths and configurations not using DTLS cookies are unaffected.

This is a moderate, narrow-trigger weakness rather than a high-real-risk priority. The vendor CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L, 6.3) correctly captures a network-reachable, unauthenticated flaw with meaningful attack complexity (AC:H) and only low integrity and low availability impact - no confidentiality loss (VC:N). CWE-330 (insufficiently random values) fits: DTLS's HelloVerifyRequest cookie exists specifically to defeat source-address spoofing and amplification, so a predictable cookie undermines that anti-spoofing control rather than leaking data. No EPSS score, no CISA KEV listing, and no public exploit are present in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' AC:H reflects that an attacker must reliably predict or reconstruct the cookie generation state, which is non-trivial and reduces practical exploitability. Note a data conflict: the 'Information Disclosure' tag contradicts the vector's VC:N - this is an anti-spoofing/randomness weakness, not a disclosure issue, and should not be triaged as a confidentiality problem.

An off-path attacker predicts the DTLS HelloVerifyRequest cookie that a NetX Secure server issues, then completes the stateless cookie exchange using a spoofed source IP address, defeating the anti-spoofing/anti-amplification protection DTLS cookies are meant to provide. This lets the attacker force the server to allocate handshake state for spoofed peers or use it as a reflector, degrading availability and integrity of connection state. No public proof-of-concept is identified, and the high attack complexity (cookie prediction) limits reliability.