Description
The TFTP server accepts a DATA datagram of any size. The dispatcher rejects datagrams shorter than



four bytes (nxd_tftp_server.c:1037) and nothing anywhere checks an upper bound, in particular not



against the protocol maximum of 4 + NX_TFTP_FILE_TRANSFER_MAX. Two things follow from that one



missing check, both reachable before any authentication because TFTP has none.



The handler passes `nx_packet_length - 4` straight to FileX:



```c



/* addons/tftp/nxd_tftp_server.c:1863, 1889 */



status = nx_packet_copy(packet_ptr, &temp_ptr,

server_ptr -> nx_tftp_server_packet_pool_ptr, NX_WAIT_FOREVER);


...



fx_file_write(&(client_request_ptr -> nx_tftp_client_request_file),

packet_ptr -> nx_packet_prepend_ptr + 4,
packet_ptr -> nx_packet_length - 4);


```



`nx_packet_length` is the length of a chain, not of one contiguous buffer, so FileX copies past the



end of the first packet:



```



ERROR: AddressSanitizer: heap-buffer-overflow



READ of size 1280 at 0x621000001108 thread T5

#0 __interceptor_memcpy
#1 _fx_utility_memory_copy filex/common/src/fx_utility_memory_copy.c:78


0x621000001108 is 0 bytes to the right of 4104-byte region



```



Those bytes are written into the file the attacker is uploading, and a TFTP read request hands them



back, so this is a memory disclosure with a convenient retrieval channel.



The same datagram also wedges the server. `nx_packet_copy` at :1863 needs



ceil(nx_packet_length / pool_payload) packets and asks for them with NX_WAIT_FOREVER, so when the



attacker sizes the datagram beyond what the pool holds, the server thread suspends and never



returns. A liveness probe after one such datagram times out with the pool at 0 of 12 packets and



the server thread suspended, and no later client is served.



Reject `nx_packet_length > 4 + NX_TFTP_FILE_TRANSFER_MAX` in the DATA branch before either call,



and use a bounded wait rather than NX_WAIT_FOREVER for the copy.
Published: 2026-09-29
Score: 8.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Data disclosure via memory overrun and denial of service
Action: Immediate Patch
AI Analysis

Impact

The NetX Duo TFTP server lacks an upper bound check on incoming DATA datagrams. An attacker can send a packet larger than the protocol maximum of 4 + NX_TFTP_FILE_TRANSFER_MAX. The dispatcher accepts the packet, copies its length without bounds checks, and forwards the buffer to FileX, which copies past the end of the first packet and writes bytes beyond the allocated region into the target file. These extraneous bytes are then recoverable to the attacker through a subsequent TFTP read request, exposing memory contents as a data disclosure. Additionally, the same oversized packet causes the server thread to block while waiting for pool resources, leading to a denial‑of‑service state that prevents all further TFTP interactions until the server is restarted. The vulnerability permits remote exploitation over UDP with no authentication required.

Affected Systems

The affected product is NetX Duo by the Eclipse Foundation. No specific version information is provided, but the flaw exists in the TFTP module as identified in the netxduo source repository.

Risk and Exploitability

The CVSS score of 8.8 indicates high severity, and the vulnerability is publicly reachable via the open network protocol TFTP without credentials. Because EPSS is unavailable, the exploitation probability cannot be quantified precisely, and the data is not listed in CISA’s KEV catalog. Nonetheless, the lack of input validation and the possibility of data disclosure and service interruption make this a critical concern for any systems running unpatched NetX Duo TFTP servers exposed untrusted networks.

Generated by OpenCVE AI on September 29, 2026 at 22:40 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the NetX Duo security patch that rejects packets longer than 4 + NX_TFTP_FILE_TRANSFER_MAX and uses a bounded wait instead of NX_WAIT_FOREVER for packet copying
  • If a patch is not immediately available, block or filter oversized TFTP DATA packets at the network perimeter or on the host with a firewall rule
  • Reconfigure or disable the TFTP service if it is not required for operational purposes

Generated by OpenCVE AI on September 29, 2026 at 22:40 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 30 Sep 2026 21:00:00 +0000

Type Values Removed Values Added
First Time appeared Eclipse
Eclipse netx Duo
Vendors & Products Eclipse
Eclipse netx Duo

Tue, 29 Sep 2026 23:00:00 +0000

Type Values Removed Values Added
Title NetX Duo TFTP Server Overflow and DoS from Oversized DATA datagrams

Tue, 29 Sep 2026 19:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Tue, 29 Sep 2026 18:00:00 +0000

Type Values Removed Values Added
Description The TFTP server accepts a DATA datagram of any size. The dispatcher rejects datagrams shorter than four bytes (nxd_tftp_server.c:1037) and nothing anywhere checks an upper bound, in particular not against the protocol maximum of 4 + NX_TFTP_FILE_TRANSFER_MAX. Two things follow from that one missing check, both reachable before any authentication because TFTP has none. The handler passes `nx_packet_length - 4` straight to FileX: ```c /* addons/tftp/nxd_tftp_server.c:1863, 1889 */ status = nx_packet_copy(packet_ptr, &temp_ptr, server_ptr -> nx_tftp_server_packet_pool_ptr, NX_WAIT_FOREVER); ... fx_file_write(&(client_request_ptr -> nx_tftp_client_request_file), packet_ptr -> nx_packet_prepend_ptr + 4, packet_ptr -> nx_packet_length - 4); ``` `nx_packet_length` is the length of a chain, not of one contiguous buffer, so FileX copies past the end of the first packet: ``` ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1280 at 0x621000001108 thread T5 #0 __interceptor_memcpy #1 _fx_utility_memory_copy filex/common/src/fx_utility_memory_copy.c:78 0x621000001108 is 0 bytes to the right of 4104-byte region ``` Those bytes are written into the file the attacker is uploading, and a TFTP read request hands them back, so this is a memory disclosure with a convenient retrieval channel. The same datagram also wedges the server. `nx_packet_copy` at :1863 needs ceil(nx_packet_length / pool_payload) packets and asks for them with NX_WAIT_FOREVER, so when the attacker sizes the datagram beyond what the pool holds, the server thread suspends and never returns. A liveness probe after one such datagram times out with the pool at 0 of 12 packets and the server thread suspended, and no later client is served. Reject `nx_packet_length > 4 + NX_TFTP_FILE_TRANSFER_MAX` in the DATA branch before either call, and use a bounded wait rather than NX_WAIT_FOREVER for the copy.
Weaknesses CWE-125
CWE-770
References
Metrics cvssV4_0

{'score': 8.8, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N'}


Subscriptions

Eclipse Netx Duo
cve-icon MITRE

Status: PUBLISHED

Assigner: eclipse

Published:

Updated: 2026-09-29T18:44:38.207Z

Reserved: 2026-09-29T16:15:09.632Z

Link: CVE-2026-102713

cve-icon Vulnrichment

Updated: 2026-09-29T18:44:34.697Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-09-29T18:17:10.457

Modified: 2026-09-29T19:17:20.290

Link: CVE-2026-102713

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-30T20:40:04Z

Weaknesses
  • CWE-125

    Out-of-bounds Read

  • CWE-770

    Allocation of Resources Without Limits or Throttling