All vulnerabilities
CVE-2026-102713GHSA-wr79-332c-ff8f

NetX Duo: 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

Eclipse Foundation NetX Duo
CVSS
8.8High
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)0.31%Chance of exploitation activity in the next 30 days, higher than 22% of CVEs. Scored 23 Oct 2026FIRST EPSS
Fixed inNone listedNo source names a fixed version. Check the vendor advisory below
Published29 Sep 2026Updated 29 Sep 2026CVE List

What fixes it

No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.

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:



/* 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.

Text from CVE List

Affected versions 1

  • NetX Duoaffected: all versions through 6.5.1.202602CVE List

References 1