CVE-2026-102713: High severity Microsoft NetX Duo vulnerability
The TFTP server accepts a DATA datagram of any size. The dispatcher rejects datagrams shorter than
four bytes (nxdtftpserver.c:1037) and nothing anywhere checks an upper bound, in particular not
against the protocol maximum of 4 + NXTFTPFILETRANSFERMAX. Two things follow from that one
missing check, both reachable before any authentication because TFTP has none.
The handler passes nxpacketlength - 4 straight to FileX:
c
/ addons/tftp/nxdtftpserver.c:1863, 1889 /
status = nxpacketcopy(packetptr, &tempptr,
serverptr -> nxtftpserverpacketpoolptr, NXWAITFOREVER);
...
fxfilewrite(&(clientrequestptr -> nxtftpclientrequestfile),
packetptr -> nxpacketprependptr + 4, packetptr -> nxpacketlength - 4);
nxpacketlength 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 interceptormemcpy #1 fxutilitymemorycopy filex/common/src/fxutilitymemorycopy.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. nxpacketcopy at :1863 needs
ceil(nxpacketlength / poolpayload) packets and asks for them with NXWAITFOREVER, 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 nxpacketlength > 4 + NXTFTPFILETRANSFERMAX in the DATA branch before either call,
and use a bounded wait rather than NXWAITFOREVER for the copy.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the TFTP DATA branch, reject any datagram where nx_packet_length > 4 + NX_TFTP_FILE_TRANSFER_MAX before calling nx_packet_copy or fx_file_write.
- Compensating control
Use a bounded wait instead of NX_WAIT_FOREVER when requesting packets for nx_packet_copy, so oversized datagrams cannot suspend the server thread indefinitely.
Event History
Frequently Asked Questions
What must an attacker be able to do to exploit this issue?
An attacker needs network access to a reachable NetX Duo TFTP server and must be able to send an oversized TFTP DATA datagram. No authentication is required, because TFTP has no authentication and the affected path is reachable before authentication.
Do undersized TFTP DATA datagrams trigger the same condition?
No. The dispatcher rejects datagrams shorter than four bytes; the issue is the absence of an upper-size check for DATA datagrams, including against the protocol maximum of 4 + NX_TFTP_FILE_TRANSFER_MAX.