NetX Duo CVE-2025-55091
MEDIUMAttack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain layer-2 network adjacency to target device
-
ExploitCraft Ethernet frame (EtherType IP, empty IP payload)
-
ExecutionTrigger out-of-bound read in _nx_ip_packet_receive()
-
ImpactLeak adjacent buffer memory contents
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the ability to deliver a raw Ethernet frame with EtherType set to IP but containing no IP data to a device running NetX Duo prior to 6.4.4; this malformed frame is the specific precondition that drives the over-read in _nx_ip_packet_receive(). No authentication or user interaction is needed (PR:N/UI:N). The practical limiting factor is network position: because the trigger is a layer-2 frame that routers would not forward intact, realistic exploitation needs adjacency to the target's broadcast domain rather than arbitrary internet reach, and the device must be running the vulnerable NetX Duo IP receive path with Ethernet link-layer input. |
| Impact | This is a genuine but moderate-priority issue, not a critical emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 6.9 and describes unauthenticated, low-complexity network reach, but the only impact metric set is VC:L (low confidentiality) with VI:N and VA:N - so the realistic consequence is a small out-of-bounds memory over-read (CWE-125) disclosing limited adjacent memory, not code execution or guaranteed denial of service. EPSS is low at 0.37% (29th percentile), there is no CISA KEV listing, and no public exploit is referenced, so the signals are internally consistent and all point to low immediate exploitation pressure rather than conflicting. One caveat worth verifying: the input marks AV:N, yet the trigger is a malformed Ethernet frame (type=IP with no IP payload), which in practice requires layer-2 adjacency because routers would not forward such a frame intact - the attack is more plausibly adjacent-network than fully remote-internet, so treat AV:N as optimistic. Net: a real defect to patch on a maintenance cadence, but not a drop-everything priority given low impact and no evidence of exploitation. |
| Exploit ScenarioDerived | An attacker with access to the same layer-2 network segment as an embedded device running NetX Duo sends a crafted Ethernet frame whose EtherType is set to IP but which carries no IP payload. The _nx_ip_packet_receive() function reads past the end of the received buffer, potentially leaking small amounts of adjacent device memory or causing unstable behavior. No public exploit code is referenced at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 08, 2026
An out-of-bounds read in Eclipse ThreadX NetX Duo (all versions before 6.4.4) is triggered in the _nx_ip_packet_receive() path when a malformed Ethernet frame declares EtherType IP but carries no IP payload, causing the parser to read past the end of the received buffer. Exploitation is unauthenticated and needs no user interaction (CVSS 4.0 PR:N/UI:N), but the trigger is a raw layer-2 frame that routers would not forward intact, so realistic exposure requires adjacency to the target's broadcast domain rather than arbitrary internet reach. EPSS is low at 0.37% (29th percentile) and no public exploit code has been identified at time of analysis; the assessed impact is limited information disclosure, with no integrity or availability effect confirmed.
RemediationAI
Vendor-released patch: upgrade to NetX Duo 6.4.4 or later, which contains the corrected _nx_ip_packet_receive() length validation; the fix and details are documented in GHSA-pf5q-r6q5-6j2f (https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-pf5q-r6q5-6j2f). Because NetX Duo is commonly vendored into OEM SDKs, confirm the actual library revision compiled into each firmware image and rebuild/redistribute firmware rather than assuming the fix propagates automatically. If upgrading immediately is not feasible, the most effective compensating control is to validate at the driver or MAC layer: reject or drop incoming Ethernet frames whose EtherType is 0x0800 but whose payload is shorter than the minimum IPv4 header (20 bytes), which requires a small patch to the platform's Ethernet input routine and must be re-applied on each SDK update. Enabling hardware MAC address filtering where available reduces the number of frames reaching the stack but does not stop an adjacent attacker from sending a frame to the device's own MAC address, and it carries the trade-off of blocking legitimate broadcast/multicast traffic if misconfigured. Segmenting the device onto a dedicated VLAN, enforcing 802.1X port authentication, and disabling unnecessary layer-2 exposure lowers the likelihood of an attacker reaching the vulnerable receive path, but these are perimeter controls with operational cost and do not remediate the over-read itself. Note that no public exploit code has been identified at time of analysis, so urgency is driven by the low-severity information-disclosure impact rather than active exploitation.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
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 networking stack maintained by the Eclipse Foundation as part of the ThreadX (formerly Azure RTOS) family, widely deployed on RTOS-based microcontrollers and IoT/edge devices. The affected component is identified by CPE cpe:2.3:a:eclipse:threadx_netx_duo:*:*:*:*:*:*:*:* (wildcard version, i.e. every release before the fixed build). The root cause is CWE-125 (Out-of-bounds Read): in _nx_ip_packet_receive(), the Ethernet receive path inspects the link-layer header and, upon seeing EtherType set to IP (0x0800), proceeds to parse what it assumes is a valid IP header without first confirming that the frame actually contains sufficient IP data. A frame with the IP EtherType but a truncated or empty payload therefore causes the routine to advance past the end of the packet buffer and read adjacent memory. This class of defect typically yields disclosure of neighboring memory contents and, depending on buffer placement and memory-protection configuration in the RTOS, can also cause an exception or fault. The vulnerable code runs in the Ethernet link-layer input path, so it is only reachable on devices configured with an Ethernet interface and the standard NetX Duo IP receive processing enabled.
Know when Threadx Netx Duo 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:L/VI:N/VA:N/SC:N/SI:N/SA:N
Malformed Ethernet frame requires layer-2 adjacency so AV:A; no auth or interaction (PR:N/UI:N); out-of-bounds read yields only limited memory disclosure (C:L), no integrity or availability impact.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
DescriptionCVE.org
In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in _nx_ip_packet_receive() function when received an Ethernet with type set as IP but no IP data.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
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
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Affected Products (CPE)CVE.org
More in Threadx Netx Duo
View allOut-of-bounds reads in the Eclipse ThreadX NetX Duo HTTP client module (all versions before 6.4.4) let a malicious, comp
In Eclipse ThreadX NetX Duo before 6.4.0, if an attacker can control parameters of __portable_aligned_alloc() could caus
A denial-of-service vulnerability exists in the NetX IPv6 component functionality of Eclipse ThreadX NetX Duo. A special
In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before version 6.4.3, an attacker can cause a denial of se
In NetX HTTP server functionality of Eclipse ThreadX NetX Duo before version 6.4.2, an attacker can cause a denial of se
An out-of-bounds read (CWE-125) in Eclipse ThreadX NetX Duo before 6.4.4 allows remote, unauthenticated attackers to rea
An out-of-bounds read in Eclipse NetX Duo's IPv4 receive path (_nx_ipv4_packet_receive()) can be triggered by delivering
Out-of-bounds read in Eclipse ThreadX NetX Duo before 6.4.4 allows unauthenticated remote attackers to trigger a limited
An out-of-bounds read in Eclipse NetX Duo before 6.4.4 allows remote, unauthenticated attackers to disclose small amount
An out-of-bounds memory read exists in Eclipse ThreadX NetX Duo's secure TLS module (all versions before 6.4.4) due to a
Out-of-bounds read in Eclipse ThreadX NetX Duo (all versions before 6.4.4) lets an attacker who can deliver DHCP traffic
Two-byte out-of-bounds read in Eclipse ThreadX NetX Duo before 6.4.4 allows a remote unauthenticated attacker to send a
Exploit-DB