---
id: "CVE-2026-115215"
kind: "vulnerability"
aliases: ["CVE-2026-115215"]
title: "Eclipse ThreadX NetX Duo: DTLS server session pool exhaustion denies service"
severity: "high"
cvss: 8.7
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: [{"name": "netxduo", "fixed": ["6.5.2.202603b"], "affected": ">= 6.0, <= 6.5.2.202603a", "ecosystem": "vendor"}]
ecosystems: []
tags: ["dtls", "eclipse", "embedded", "infrastructure", "iot", "netx-duo", "rtos", "threadx"]
not_affected_if: ["dtls-client-only", "no-dtls-server", "other-tls-stack"]
published_at: "2026-11-02T22:17:18+00:00"
first_seen_at: "2026-11-02T22:35:42+00:00"
updated_at: "2026-11-02T22:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115215", "first_seen_at": "2026-11-02T22:35:42+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-02T22:38:50+00:00"}]
---

# Eclipse ThreadX NetX Duo: DTLS server session pool exhaustion denies service

The NetX Secure DTLS server in Eclipse ThreadX NetX Duo reserves a session from a fixed pool for the first datagram from any unknown address before the cookie exchange, and never frees sessions whose handshake stalls. A remote unauthenticated attacker can send one spoofed datagram per source to fill the pool and block legitimate DTLS clients until the application resets the sessions.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:netxduo affected >= 6.0, <= 6.5.2.202603a fixed 6.5.2.202603b

## How to check

- Check whether your firmware builds NetX Duo with the NetX Secure DTLS server (nx_secure_dtls_server_*); DTLS clients are unaffected and no build option disables the flaw.
- Check the NetX Duo version in your source tree or SDK: 6.0 through 6.5.2.202603a are affected; 6.5.2.202603b is fixed.

## Fix

Upgrade NetX Duo to 6.5.2.202603b. Optionally supply a cookie secret with nx_secure_dtls_server_cookie_secret_set (otherwise drawn from NX_RAND). Workaround if you cannot upgrade: reset sessions whose handshake has not completed within a timeout using nx_secure_dtls_session_reset() or nx_secure_dtls_session_end(); this frees slots but does not stop a burst filling the pool. Ingress filtering against source-address spoofing reduces exposure upstream.

## Timeline

- 2026-11-02T22:35:42+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-115215
- 2026-11-02T22:38:50+00:00 analyst — Read Eclipse ThreadX GHSA-3p2g-x7hh-3w4c and release page: fixed in 6.5.2.202603b; affected >=6.0 <=6.5.2.202603a. No exploitation or PoC mentioned.

## Documents

- [advisory] Vendor advisory: github.com https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-3p2g-x7hh-3w4c
- [fix] NetX Duo release v6.5.2.202603b_rel https://github.com/eclipse-threadx/netxduo/releases

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_