CVE-2026-106465: NetX Secure DTLS server missing HelloVerifyRequest cookie validation

CVE-2026-106465 · Severity: info · Published 2026-10-14

The NetX Secure DTLS server, which provides secure datagram communication for embedded systems, fails to validate the cookie it sends during the connection handshake. An attacker can send a forged ClientHello with any single cookie byte to bypass verification and establish sessions from spoofed addresses, enabling denial-of-service attacks that exhaust the server's session pool and reflect traffic amplification at third parties.

Technologies: Eclipse ThreadX NetX Duo. Vendors: Eclipse ThreadX.

Quick answers

Is CVE-2026-106465 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-106465 being exploited in the wild.
How severe is CVE-2026-106465?
Informational severity, published 14 October 2026.
Which products and versions are affected?
Eclipse ThreadX NetX Duo <= 6.5.2.202603.
Is there a fix for CVE-2026-106465?
Yes: fixed in NetX Duo 6.5.2.202603a. Until then: No workarounds within the DTLS server itself. Ingress filtering to prevent source-address forgery reduces exposure, and limiting sessions per peer mitigates pool exhaustion, but neither restores the verification the cookie exchange provides. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-106465 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-106465?
Check whether you run Eclipse ThreadX NetX Duo at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • Fixed in: NetX Duo 6.5.2.202603a

No workarounds within the DTLS server itself. Ingress filtering to prevent source-address forgery reduces exposure, and limiting sessions per peer mitigates pool exhaustion, but neither restores the verification the cookie exchange provides.

Technical details

The DTLS server generates a 20-byte random cookie in HelloVerifyRequest but the ClientHello parser copies the client's cookie directly into the same field without comparison, destroying the issued cookie. The server then verifies the client only by checking whether the cookie length is non-zero, allowing an attacker to skip the return-routability check by including any single byte. This enables session exhaustion and reflection amplification on forged source addresses.

Affected products

  • Eclipse ThreadX NetX Duo <= 6.5.2.202603

Timeline

  • 2026-10-14: disclosed
  • 2026-10-13: patched

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.