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.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 6.5.2.202603b
- Who is exposed
- Default setups
Do first: Check every install: default setups are affected.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 31/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Default setups
- Fix
- Fixed in 6.5.2.202603b
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
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.
Read the original 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 every install: default setups are affected.
Upgrade to a fixed version: 6.5.2.202603b.
Workaround: Reset, with nx_secure_dtls_session_reset() or nx_secure_dtls_session_end(), any session whose handshake has not completed within a chosen timeout; this does not prevent a burst of forged datagrams from filling the pool
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Eclipse Foundation Eclipse ThreadX
From 6.0 · through 6.5.2.202603a
Evidence 2
- Advisory
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-115215
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: github.com
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: github.com
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: github.com
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: cve.now feed data