CVE-2026-102721: Medium severity Microsoft NetX Duo vulnerability
A TFTP server that answers with a short ERROR packet makes the client read up to 64 bytes past the
received datagram.
Each receive path checks only that the datagram is at least four bytes long (nxdtftpclient.c:1229,
1521, 1984). When the opcode is NXTFTPCODEERROR the message string is copied with a loop whose
only limits are the destination buffer and a NUL byte:
c
/ addons/tftp/nxdtftpclient.c:1769 /
for (i = 0; (i < (sizeof(tftpclientptr -> nxtftpclienterrorstring) - 1)) && (bufferptr); i++)
Nothing compares bufferptr against nxpacketappendptr. An ERROR packet that carries no
terminating NUL, which a server controls completely, walks the loop off the end of the packet until
it happens to meet a zero byte or fills the 64 byte destination.
ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 1 at 0x60d0000000c8 thread T4
#0 nxdtftpclientfileread addons/tftp/nxdtftpclient.c:1769
0x60d0000000c8 is 0 bytes to the right of 136-byte region
The open path has the same loop at :1327 and reports the same way. What is read lands in
nxtftpclienterrorstring, which the application is expected to display or log, so adjacent
packet pool memory ends up in whatever the device does with the error text.
Add (bufferptr < packetptr -> nxpacketappendptr) to the loop condition in all three paths.
Affected Software
Event History
Frequently Asked Questions
Which systems are realistically exposed?
NetX Duo TFTP clients are exposed when they communicate with a TFTP server that an attacker can control or impersonate. The issue is in client-side handling of TFTP ERROR responses, not in processing of ordinary data packets described here.
What does an attacker need to send to trigger the out-of-bounds read?
The attacker needs to cause the client to receive a TFTP ERROR packet that is at least four bytes long but whose message field has no terminating NUL byte. The server controls the ERROR packet contents completely.
Which client operations reach the vulnerable handling?
Both the TFTP open path and file-read path contain the unbounded error-message copy loop. Each path checks only that the received datagram is at least four bytes before processing an ERROR opcode.
How might this be detected during testing?
AddressSanitizer reports a heap-buffer-overflow read at the error-message copy loop, including at nxd_tftp_client.c:1769 for the file-read path. The report shows the read occurring immediately past a 136-byte allocated region.