CVE-2026-102715: CWE-787 Out-of-bounds Write in Eclipse Foundation eclipse-threadx/netxduo
Any host on the LAN can send two mDNS records and make the responder write past the end of its transmit packet. The string table stores each name in a slot rounded up to a multiple of four: ```c /* addons/mdns/nxd_mdns.c:11436, 11443, 11447 */ memory_len = ((memory_len & 0xFFFFFFFC) + 8) & 0xFFFFFFFF; ... len = *((USHORT*)(p - 2)); /* slot size, not string length */ if ((len == memory_len) && ... _nx_mdns_name_match(start, memory_ptr, memory_size) ...) ``` The lookup that decides whether an incoming name is already stored compares the rounded slot size, so names of 12, 13, 14 and 15 characters share one bucket. A second name in the bucket is answered with the pointer to the first, and the record then carries a string up to three bytes longer than the length the caller accounted for. `_nx_mdns_packet_rr_add` (nxd_mdns.c:8911) sizes its only bound check from that stale length, and `_nx_mdns_name_string_encode` writes the real string. Two PTR records are enough, both ordinary mDNS responses to a `_http._tcp` query, with owner names whose lengths fall in the same bucket: ``` ==87491==ERROR: AddressSanitizer: heap-buffer-overflow WRITE of size 1 at 0x611000000124 thread T5 #0 _nx_mdns_name_string_encode addons/mdns/nxd_mdns.c:13096 #1 _nx_mdns_packet_rr_add addons/mdns/nxd_mdns.c:8911 0x611000000124 is 0 bytes to the right of 228-byte region ``` The overflow is one to three bytes of attacker-influenced name data past `nx_packet_data_end`. In a normal pool that lands in the next packet in the same pool rather than in a redzone, so the visible effect is a corrupted neighbouring packet or a corrupted pool free list rather than a clean crash. Compare the slot size against the stored string length before declaring a match, or keep the string length in the slot header and return it to the caller so the encoder and the bound check agree.
AI Analysis
Technical Summary
The vulnerability arises from how the mDNS responder stores and compares name strings in a string table with slots rounded to multiples of four bytes. The lookup logic uses the rounded slot size rather than the actual string length, causing different length names (e.g., 12 to 15 characters) to share a bucket. When a second name in the bucket is processed, the responder uses the pointer to the first name but encodes the full length of the second name, leading to a write beyond the allocated buffer in _nx_mdns_name_string_encode. This results in a heap buffer overflow of one to three bytes past the packet data end, potentially corrupting neighboring packets or pool metadata.
Potential Impact
An attacker on the local network can exploit this vulnerability to cause heap corruption in the mDNS responder. While this may not immediately cause a crash, it can lead to data corruption or destabilize the service. The CVSS 4.0 score is 7.1 (high), reflecting the local network attack vector, low complexity, no privileges required, no user interaction, and high impact on availability.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, network administrators should consider restricting or monitoring mDNS traffic on local networks to mitigate potential exploitation. The vendor has not provided an official fix or patch link at this time.
CVE-2026-102715: CWE-787 Out-of-bounds Write in Eclipse Foundation eclipse-threadx/netxduo
Description
Any host on the LAN can send two mDNS records and make the responder write past the end of its transmit packet. The string table stores each name in a slot rounded up to a multiple of four: ```c /* addons/mdns/nxd_mdns.c:11436, 11443, 11447 */ memory_len = ((memory_len & 0xFFFFFFFC) + 8) & 0xFFFFFFFF; ... len = *((USHORT*)(p - 2)); /* slot size, not string length */ if ((len == memory_len) && ... _nx_mdns_name_match(start, memory_ptr, memory_size) ...) ``` The lookup that decides whether an incoming name is already stored compares the rounded slot size, so names of 12, 13, 14 and 15 characters share one bucket. A second name in the bucket is answered with the pointer to the first, and the record then carries a string up to three bytes longer than the length the caller accounted for. `_nx_mdns_packet_rr_add` (nxd_mdns.c:8911) sizes its only bound check from that stale length, and `_nx_mdns_name_string_encode` writes the real string. Two PTR records are enough, both ordinary mDNS responses to a `_http._tcp` query, with owner names whose lengths fall in the same bucket: ``` ==87491==ERROR: AddressSanitizer: heap-buffer-overflow WRITE of size 1 at 0x611000000124 thread T5 #0 _nx_mdns_name_string_encode addons/mdns/nxd_mdns.c:13096 #1 _nx_mdns_packet_rr_add addons/mdns/nxd_mdns.c:8911 0x611000000124 is 0 bytes to the right of 228-byte region ``` The overflow is one to three bytes of attacker-influenced name data past `nx_packet_data_end`. In a normal pool that lands in the next packet in the same pool rather than in a redzone, so the visible effect is a corrupted neighbouring packet or a corrupted pool free list rather than a clean crash. Compare the slot size against the stored string length before declaring a match, or keep the string length in the slot header and return it to the caller so the encoder and the bound check agree.
CVSS v4.0
Score 7.1high
Affected software
Eclipse Foundation
eclipse-threadx/netxduo
pkg:github/eclipse-threadx/netxduoRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability arises from how the mDNS responder stores and compares name strings in a string table with slots rounded to multiples of four bytes. The lookup logic uses the rounded slot size rather than the actual string length, causing different length names (e.g., 12 to 15 characters) to share a bucket. When a second name in the bucket is processed, the responder uses the pointer to the first name but encodes the full length of the second name, leading to a write beyond the allocated buffer in _nx_mdns_name_string_encode. This results in a heap buffer overflow of one to three bytes past the packet data end, potentially corrupting neighboring packets or pool metadata.
Potential Impact
An attacker on the local network can exploit this vulnerability to cause heap corruption in the mDNS responder. While this may not immediately cause a crash, it can lead to data corruption or destabilize the service. The CVSS 4.0 score is 7.1 (high), reflecting the local network attack vector, low complexity, no privileges required, no user interaction, and high impact on availability.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, network administrators should consider restricting or monitoring mDNS traffic on local networks to mitigate potential exploitation. The vendor has not provided an official fix or patch link at this time.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- eclipse
- Date Reserved
- 2026-09-29T16:15:11.235Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6abbfcc9107c4a03cbb2801b
Added to database: 09/29/2026, 18:00:41 UTC
Last enriched: 09/29/2026, 18:01:46 UTC
Last updated: 09/29/2026, 18:51:53 UTC
Views: 5
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.