EUVD-2026-89180
GHSA-4637-2x4v-2wq5
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
ReconReach exposed RTSP server port
-
DeliverySend request with unparseable Session header
-
ExploitParser returns raw NetX error
-
InstallError path leaks response packet block
-
C2Repeat ~26 times to drain pool
-
ExecutePacket pool exhausted, allocations fail
-
ImpactServer/stack denial of service
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Resource cleanup, leak prevention
|
| Exploitation Conditions | Requires the target to run the NetX Duo RTSP server addon (addons/rtsp/nx_rtsp_server.c) reachable over the network; no authentication, user interaction, or non-default configuration is needed - an unauthenticated client simply sends RTSP requests bearing a Session header value that _nx_utility_string_to_uint cannot convert (empty or non-numeric). The realistic limiting factors are: the device must expose the RTSP service, and impact scales with packet-pool size (the shipped sample uses a 22-block pool exhausted by ~26 requests). Blast radius is worst when the RTSP server shares its packet pool with the rest of the application, in which case pool exhaustion halts the entire networking stack rather than only RTSP; a dedicated pool would confine the DoS to the RTSP service. |
| Impact | This is a genuine but bounded risk. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VA:H, VC:N/VI:N) is internally consistent with the description: an unauthenticated remote attacker reaches the flaw over the network with no user interaction and no special conditions, and the impact is purely availability - no confidentiality or integrity loss. My independent CVSS 3.1 read is ~7.5 (AV:N/AC:L/PR:N/UI:N, A:H only). The 'Buffer Overflow' tag conflicts with the actual mechanism: this is CWE-401 (missing packet-pool block release / memory leak), not a memory-corruption overflow - VC:N/VI:N confirm there is no code-execution or disclosure primitive here, so it should not be triaged as an RCE-class bug. No EPSS score, no CISA KEV listing, and no public POC are provided, so there is no evidence of active exploitation; the practical severity is a reliable, low-effort denial of service (~26 requests) rather than a high-CVSS-but-theoretical issue. The realistic-priority driver is that exploitation is trivial and deterministic against any exposed RTSP server, and - because the sample ships a shared packet pool - a successful drain can halt the entire networking stack, not just RTSP. |
| Exploit ScenarioDerived | An attacker with network reach to a device running the NetX Duo RTSP server addon sends roughly two-dozen RTSP requests carrying an empty or non-numeric Session header that the parser cannot convert. Each malformed request leaks one packet-pool block that is never returned, and after ~26 requests the 22-block pool is exhausted, so the server (and any application sharing the pool) can no longer allocate packets and stops serving traffic. No authentication, user interaction, or POC is required; exploitation is a short scripted loop of TCP requests. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 29, 2026
Unauthenticated remote clients can exhaust the packet pool of the Eclipse ThreadX NetX Duo RTSP server addon, causing a denial of service: roughly two dozen RTSP requests carrying a Session header value that the parser cannot convert (empty or non-numeric) leak one packet block each until the pool hits zero and the server can no longer serve any client. The leak occurs because the Session branch of _nx_rtsp_server_error_response_send's caller returns the raw NetX error code instead of mapping it to an RTSP status, and the error-response path then drops the already-allocated response packet on that unrecognized code. No public exploit identified at time of analysis, and no CISA KEV entry was provided; the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms remote, unauthenticated, availability-only impact, with blast radius worst when the RTSP server shares its packet pool with the rest of the application, as in the shipped sample (22-block pool exhausted by ~26 requests).
RemediationAI
No vendor-released patch version is identified in the provided data; consult the Eclipse advisory GHSA-q462-246c-x3jc (https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-q462-246c-x3jc) for the exact fixed release and track it before upgrading, since the input does not supply a verifiable version string. The upstream fix described is twofold: map the _nx_utility_string_to_uint failure in the Session branch to NX_RTSP_STATUS_CODE_BAD_REQUEST exactly as the CSeq branch at line 2736 does, and release the response packet on every exit path of _nx_rtsp_server_error_response_send so the unrecognized-code path no longer leaks. Where an immediate upgrade is not possible, the most effective compensating control is to stop exposing the RTSP service to untrusted networks: block or restrict the RTSP listener port (554 by default, or whatever port the addon is bound to) at the firewall or gateway so only known clients can reach it - the trade-off is that any client able to reach the port can still drain the pool until patched. Second, give the RTSP server its own dedicated packet pool instead of sharing the application pool, as the shipped sample does; this does not stop the leak but confines the denial of service to RTSP rather than taking the whole networking stack down, at the cost of additional reserved memory. Third, add external supervision that monitors packet-pool availability and restarts or resets the RTSP service when free blocks fall toward zero, buying time until the service can be restarted cleanly; this is disruptive to legitimately connected clients. Client-side or edge-level validation that rejects RTSP requests with empty or non-numeric Session headers is only a partial measure, because the leak happens inside the parser before application-level logic and depends on the intermediary covering every request path.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
NetX Duo is the embedded IPv4/IPv6 TCP/IP stack from Eclipse ThreadX, and its optional RTSP server addon lives in addons/rtsp/nx_rtsp_server.c. The defect is CWE-401 (Missing Release of Memory after Effective Lifetime) - a packet-block leak rather than a classic buffer overflow, despite the 'Buffer Overflow' tag carried in the intelligence feed. At line 2754, the Session header is converted via _nx_utility_string_to_uint; when that call fails it can return NX_INVALID_PARAMETERS, NX_SIZE_ERROR, or NX_OVERFLOW, and the Session branch returns that raw NetX status directly. Every other branch of the same function normalizes failures to an RTSP status first - the CSeq branch eighteen lines earlier (line 2736) returns NX_RTSP_STATUS_CODE_BAD_REQUEST. The unmapped code propagates to _nx_rtsp_server_error_response_send (line 1234), which does not recognize it and takes an exit path that returns without freeing the response packet it had already allocated. That block never re-enters the pool and is not reclaimed when the client disconnects, so allocation failure is cumulative. The provided CPE (cpe:2.3:a:eclipse_foundation:eclipse-threadx/netxduo:*:*:*:*:*:*:*:*) applies a wildcard version range, indicating the leak is present in the NetX Duo codebase generally for builds that compile in the RTSP server addon; deployments that link only the core stack are unaffected. Because the pool is a shared resource, exhaustion degrades or halts any other component drawing from the same pool, which is exactly the configuration used by the shipped sample.
Know when Eclipse Threadx Netxduo gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Unauthenticated remote attacker triggers deterministic packet-pool exhaustion with trivial requests (AV:N/AC:L/PR:N/UI:N); impact is availability-only leak, no confidentiality or integrity.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
DescriptionCVE.org
An unauthenticated client can drain the RTSP server's packet pool with a couple of dozen requests
that carry a Session header the parser cannot convert.
The Session branch returns the raw NetX error code instead of an RTSP status code:
/* addons/rtsp/nx_rtsp_server.c:2754 */
status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &session_id);
if (status)
{
return(status); /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */
}
Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch
eighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The
raw code then reaches _nx_rtsp_server_error_response_send (nx_rtsp_server.c:1234), which does not
recognise it, takes a path that returns without releasing the response packet it already allocated,
and the block never goes back to the pool.
Six requests with an empty Session header against a 22 packet pool:
valid requests: after request 6: pool available = 21, AFTER = 22 / 22
malformed requests: after request 6: pool available = 16, AFTER = 17 / 22
One block per request, not returned when the client disconnects. Twenty six requests take the pool
to zero and the server starts failing allocations, after which it serves nobody. If the pool is
shared with the rest of the application, as it is in the shipped sample, the rest of the stack
stops with it.
Convert the _nx_utility_string_to_uint failure in the Session branch into
NX_RTSP_STATUS_CODE_BAD_REQUEST the way the CSeq branch does, and release the response packet on
every exit path of _nx_rtsp_server_error_response_send.
Executive ViewAI
Eclipse ThreadX NetX Duo RTSP server addon is vulnerable to a remote, unauthenticated denial-of-service that can exhaust the packet pool, disrupting service for all clients. Organizations using this component in embedded or real-time systems should prioritize mitigation because no vendor patch is currently available and a successful attack can halt RTSP streaming, impacting dependent operations. Leadership should care because this affects availability of critical services, and the blast radius extends if the RTSP server shares its packet pool with other application functions.
Block RTSP requests with empty or non-numeric Session headers at network perimeter (e.g., via WAF or firewall rule). Isolate the RTSP server's packet pool from other application components if possible. Implement rate limiting on RTSP connections. Monitor packet pool usage for signs of exhaustion. Disable the RTSP server if not operationally required.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
More in Eclipse Threadx Netxduo
View allHeap out-of-bounds write in the mDNS responder of Eclipse ThreadX NetX Duo allows an unauthenticated attacker on the sam
An out-of-bounds heap read in the DHCP client addon of Eclipse ThreadX NetX Duo (nxd_dhcp_client.c) allows an attacker o
Exploit-DB