EUVD-2026-89184
GHSA-rw53-r2p7-qgmf
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain local-link position or race the DISCOVER
-
DeliverySend crafted DHCP OFFER with many skippable options
-
ExploitOffset counter drifts behind read pointer
-
ExecutionClient reads ~1KB past message end
-
ImpactLeaked heap bytes applied to interface config and become observable
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 | Requires the DHCP client addon of NetX Duo to be active and the device to be performing DHCP acquisition (which occurs on every boot while the interface is unconfigured). The attacker must be on the same local link - either operating a DHCP server or any LAN host that wins the race to answer the client's broadcast DISCOVER before the legitimate server - and must send a single OFFER whose option area contains a long run of skippable TLV options so the offset counter drifts far enough behind the read pointer. Limiting factors: exploitation is adjacent-network only (not routable/internet-facing), impact is a bounded out-of-bounds read (no write/code execution), and it is opportunistic against booting/renewing clients within the attacker's link. |
| Impact | This is a genuine but bounded-severity issue rather than a critical priority. The vendor CVSS 4.0 vector (AV:A/AC:L/PR:N/UI:N/VC:L/VI:N/VA:L, base 5.3) is internally consistent with the description: exploitation is unauthenticated and low-complexity but confined to the local link (adjacent, not full network), and impact is limited to a low-confidentiality leak plus low availability impact. No EPSS score, no CISA KEV listing, and no public exploit are present in the provided intelligence, so exploitation status is 'no public exploit identified at time of analysis.' The primary factors that keep real-world risk moderate rather than high are the adjacency requirement (attacker must be on the same LAN or a rogue/racing DHCP responder) and the low technical impact (a ~1KB out-of-bounds read, not code execution or a write primitive). One tension worth verifying: the 'Buffer Overflow' tag and CWE-125 describe an out-of-bounds READ, not a classic overflow write - there is no memory-corruption/write primitive here despite the overflow tag. The 'Information Disclosure' tag is accurate for this CVE because the over-read bytes are used to configure the interface and thus become observable, unlike some sibling NetX Duo read bugs where the leak stays internal. |
| Exploit ScenarioDerived | A rogue DHCP server on the LAN - or any host that answers the client's broadcast DISCOVER before the legitimate server - sends a crafted OFFER containing a long run of skippable TLV options. Because the option-walk advances the read pointer by size+2 per option but its bound counter by only size+1, the counter lags one byte per skipped option until the pointer runs past the end of the received message while the bound check still passes, causing the client to read roughly a kilobyte of adjacent heap memory. No authentication or user interaction is required and complexity is low, but the attacker must be on the local link; no public exploit code is identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 29, 2026
An out-of-bounds heap read in the DHCP client addon of Eclipse ThreadX NetX Duo (nxd_dhcp_client.c) allows an attacker on the same local link to disclose adjacent heap memory whenever a device performs a DHCP acquisition. The attacker only needs to be a DHCP server, or any LAN host that wins the race to answer the client's broadcast DISCOVER first, and to reply with a single OFFER containing a long run of skippable TLV options; a malformed option layout causes the parser's offset counter to lag the actual read pointer, producing a read roughly a kilobyte and beyond past the end of the message (a one-byte read 164 bytes past a 1648-byte heap region in the reported AddressSanitizer trace). The issue occurs unauthenticated (CVSS PR:N), from an adjacent network (AV:A), on every boot while the interface is unconfigured, with bounded impact limited to low confidentiality and low availability (CVSS 5.3); no public exploit code or confirmed active exploitation was identified at time of analysis.
RemediationAI
Upstream remediation is a code fix in addons/dhcp/nxd_dhcp_client.c: advance the offset counter by size + 2 rather than size + 1, or better, derive the loop bound directly from the data pointer instead of maintaining a second, drift-prone counter, and add an explicit check that at least two bytes (type plus length) remain before reading them. The Eclipse ThreadX NetX Duo security advisory GHSA-8hj5-p46x-5h28 (https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-8hj5-p46x-5h28) is the authoritative source for the patched release; an exact fixed version is not identified in the provided data, so integrators should track that advisory rather than assuming a version number. Where patching is not immediately possible, the most effective compensating control is to stop the process from being influenced by untrusted DHCP responders: on managed switches enable DHCP snooping with only the legitimate server's port trusted, and apply port security or 802.1X to keep unauthorized hosts off the link - the trade-off is that this requires managed network infrastructure and correct trust-port configuration, and misconfiguration can black-hole legitimate clients. Restricting the device to a dedicated, physically controlled management segment reduces the attacker population but does not eliminate the risk from a compromised peer on that segment. Statically configuring the interface and disabling or not compiling the DHCP client addon removes the attack surface entirely, at the cost of losing zero-touch provisioning, address failover, and the operational flexibility of DHCP (it also requires reflashing or rebuilding firmware for most NetX Duo deployments). Because the impact is a bounded out-of-bounds read with no write primitive, session encryption or application-layer authentication around the DHCP exchange is not achievable - there is no supported authenticated DHCP mode to fall back on - so network segmentation and the code fix remain the primary defenses.
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
The flaw is a classic pointer/offset desynchronization during parsing of DHCP TLV (type-length-value) options; the CWE-125 out-of-bounds read class applies. In the DHCP client option walk (addons/dhcp/nxd_dhcp_client.c around lines 7538 and 7572), the loop condition bounds the walk using the integer offset i (while (i < length - 1)), while the actual read position is the pointer data. For each skipped option the code advances data by size + 2 (one byte for the type, one for the length, plus size payload bytes) but advances i by only size + 1, so the counter drifts one byte further behind the real read position for every option skipped. DHCP option bytes are attacker-controlled because they arrive in an untrusted OFFER, and a single OFFER carrying a sufficiently long run of skippable options lets i still satisfy i < length - 1 while data has already passed the end of the received message; the subsequent read of the next type and length bytes (_nx_dhcp_search_buffer, reached via _nx_dhcp_get_option_value) then reads from whatever heap memory follows the message buffer. The affected product is identified by the CPE cpe:2.3:a:eclipse_foundation:eclipse-threadx/netxduo:*:*:*:*:*:*:*:* (all versions), i.e. the Eclipse Foundation ThreadX NetX Duo embedded TCP/IP stack, and specifically the DHCP client addon component of that stack. The values read are consumed by the client to configure the interface, which is the channel by which disclosed heap bytes become observable to the attacker. A well-formed OFFER over the same code path is processed normally (the client records the offer and transitions to REQUESTING), confirming that the trigger is the option layout rather than any harness or environmental artifact. The read executes in the DHCP client thread while the interface is still unconfigured, so any device in reach of a hostile DHCP responder exercises this path on every boot or lease renewal.
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:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N
Adjacent-LAN rogue/racing DHCP responder needs no auth or interaction (AV:A/AC:L/PR:N/UI:N); bounded ~1KB over-read yields low confidentiality and possible crash gives low availability, no write so I:N.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
DescriptionCVE.org
A DHCP server, or anyone on the LAN who answers a DISCOVER first, can make the client read about a
kilobyte past the end of the received message.
The option walk keeps a pointer and an offset in step, and the only bound check uses the offset:
/* addons/dhcp/nxd_dhcp_client.c:7538, 7572 */
while (i < length - 1)
{
...
size = *(++data); /* data moves 1: type -> length byte */
data += size + 1; /* data moves size + 1 more */
i += size + 1; /* i moves only size + 1 */
}
A TLV option occupies size + 2 bytes. data is advanced by size + 2 in total, i by size + 1, so
the offset falls one byte behind the real read position for every option the walk skips. After
enough skipped options the check i < length - 1 still holds while data is already past the end
of the message, and the subsequent read of the type and length bytes comes from whatever follows.
A single OFFER carrying a long run of skippable options is enough:
ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 1 at 0x61b000000794 thread T5
#0 _nx_dhcp_search_buffer addons/dhcp/nxd_dhcp_client.c:7541
#1 _nx_dhcp_get_option_value addons/dhcp/nxd_dhcp_client.c:7082
0x61b000000794 is located 164 bytes to the right of 1648-byte region
A well formed OFFER through the same path is handled normally, the client records the offer and
moves to REQUESTING, so the difference is the option layout rather than the harness.
The read runs in the DHCP client thread while the client is still unconfigured, so it happens on
every boot in reach of a hostile DHCP responder. The values read are used to configure the
interface, which is how the disclosed bytes become observable.
Advance i by size + 2, or derive the bound from data rather than keeping a second counter.
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
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.
More in Eclipse Threadx Netxduo
View allUnauthenticated remote clients can exhaust the packet pool of the Eclipse ThreadX NetX Duo RTSP server addon, causing a
Heap out-of-bounds write in the mDNS responder of Eclipse ThreadX NetX Duo allows an unauthenticated attacker on the sam
Exploit-DB