---
id: CVE-2026-102713
title: The TFTP server accepts a DATA datagram of any size
summary: >-
  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 …
severity: high
cvss: 8.8
cvssVector: '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'
cwe:
  - CWE-125
  - CWE-770
vendor: Eclipse Foundation
product: NetX Duo
affected:
  - netx_duo <= 6.5.1.202602
published: '2026-09-29'
updated: '2026-09-29'
sourceUpdated: '2026-09-29T18:17:10.457'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-102713'
references:
  - url: >-
      https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-wr79-332c-ff8f
    label: emo@eclipse.org
tags:
  - nvd
  - cve.org
cvssSource: cna
ingestedAt: '2026-09-29T18:42:35.813Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.