NetX Duo CVE-2026-115215

Exploitation requires the target to run the NetX Secure DTLS *server* role on an affected build (NetX Duo 6.0 through 6.5.2.202603a); DTLS clients are not affected, and the vulnerable allocation is in the common DTLS receive path with no build option gating it. Per PR:N/UI:N the attack is unauthenticated and needs no user interaction, and the attacker need not receive any reply, so source-address spoofing works directly. Effectiveness scales with the application-configured nx_dtls_server_sessions_count, which is fixed and typically small on embedded targets, so only a few forged datagrams are needed. Limiting factors: the server must expose the DTLS service to the attacker's network path; applications that reset or end stalled handshakes via nx_secure_dtls_session_reset()/nx_secure_dtls_session_end() within a chosen timeout bound the exposure (though not a mid-burst flood); and upstream ingress filtering against source-address forgery reduces reach. Impact is availability-only - confidentiality and integrity are unaffected.

This is a genuine but bounded availability risk, not an overhyped high-CVSS finding. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms a network-reachable, low-complexity, unauthenticated flaw requiring no user interaction and no attack-requirement preconditions - all signals that favor easy exploitation - while impact is strictly availability (VC:N/VI:N/VA:H, no confidentiality or integrity effect), consistent with a resource-exhaustion DoS (CWE-770/CWE-772). The vuln.today decision label is 'this_week' rather than act_now/emergency, which aligns with a service-denial impact on a specific embedded feature rather than code execution or data compromise. No EPSS score and no KEV listing are present in the input, and there is no confirmed public exploit code - the issue was found internally by an Eclipse researcher (Frédéric Desbiens) while reviewing a prior fix, and the only public artifacts are vendor advisories, not weaponized PoC. The low-friction exploitation path (one spoofed datagram per source, no reply needed) is partly offset by the fact that it only affects deployments that actually enable the NetX Secure DTLS server and that recovery is possible via application-level session reset. Net: real and worth patching promptly for anyone running the DTLS server, but it is a denial-of-service against an optional RTOS networking component, not a widespread critical-impact emergency.

A remote, unauthenticated attacker sends a single UDP/DTLS datagram (at least a record header long, non-alert) from each of many forged source address/port tuples to a device running the NetX Secure DTLS server. Each unrecognized source causes the server to allocate a session from its small fixed pool before any cookie verification, and stalled handshakes are never reclaimed by the library, so a handful of spoofed packets exhausts the pool and locks out legitimate clients. No public exploit code is identified at time of analysis, though the low complexity (AC:L) and absence of required reply traffic make the attack trivial to script.