CVE-2026-102721 in NetX Duo
Summary
by MITRE • 09/29/2026
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 (nxd_tftp_client.c:1229,
1521, 1984). When the opcode is NX_TFTP_CODE_ERROR the message string is copied with a loop whose
only limits are the destination buffer and a NUL byte:
```c
/* addons/tftp/nxd_tftp_client.c:1769 */
for (i = 0; (i < (sizeof(tftp_client_ptr -> nx_tftp_client_error_string) - 1)) && (*buffer_ptr); i++)
```
Nothing compares `buffer_ptr` against `nx_packet_append_ptr`. 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 _nxd_tftp_client_file_read addons/tftp/nxd_tftp_client.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
`nx_tftp_client_error_string`, 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 `(buffer_ptr < packet_ptr -> nx_packet_append_ptr)` to the loop condition in all three paths.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability described constitutes a heap-based buffer overflow within the NetX Duo TFTP client implementation, specifically affecting the handling of ERROR packets received from a remote Trivial File Transfer Protocol server. This flaw arises from insufficient boundary checking during the processing of error responses, allowing an attacker to read memory beyond the allocated packet buffer and potentially leak sensitive information or cause a denial of service through application instability. The root cause lies in the logic used to copy the error message string into the local `nx_tftp_client_error_string` buffer. While the code correctly verifies that the incoming datagram is at least four bytes long, it fails to validate whether the payload length actually contains enough data to satisfy the loop's termination condition based on a null terminator or safe memory boundaries.
The technical flaw manifests in three distinct receive paths within the `nxd_tftp_client.c` source file, specifically around lines 1229, 1327, and 1521, with the primary execution path identified at line 1769. The loop responsible for copying the error string iterates through bytes in the received packet buffer until it either fills a sixty-four-byte destination limit or encounters a null byte character. However, the code does not compare the current read pointer against the end of the allocated memory region defined by `nx_packet_append_ptr`. Consequently, if an attacker crafts and sends a TFTP ERROR packet that lacks a terminating NUL byte within its payload, the loop will continue reading past the end of the valid datagram. This results in out-of-bounds reads into adjacent heap memory regions managed by the NetX Duo network stack's packet pool.
The operational impact of this vulnerability is significant due to the nature of the data being read and where it lands. The overflowed bytes are written into `nx_tftp_client_error_string`, a buffer intended for display or logging purposes. This means that adjacent memory contents, which may include other application data, network packet headers, or sensitive configuration information, can be exfiltrated through error messages displayed to the user or logged by the system. Furthermore, reading arbitrary heap memory can lead to unpredictable behavior if the read values influence subsequent control flow or logic decisions within the TFTP client state machine. In severe cases, this could facilitate further exploitation vectors such as use-after-free scenarios or information disclosure that aids in bypassing other security controls.
From a classification perspective, this vulnerability aligns with CWE-126: Buffer Over-read and CWE-787: Out-of-bounds Read. The lack of proper input validation for the length of the error string relative to the allocated buffer size is characteristic of these weaknesses. In terms of attack patterns, this could be leveraged in an Information Disclosure scenario within the MITRE ATT&CK framework, where an adversary sends a specially crafted TFTP response to extract internal memory states from the target device. The vulnerability highlights the critical importance of validating not just the presence of data but also its structural integrity and boundaries when processing network protocols that allow server-controlled payloads.
To mitigate this risk, developers must modify the loop conditions in all three affected receive paths within `nxd_tftp_client.c`. Specifically, the condition `(buffer_ptr < nx_packet_append_ptr)` should be added to ensure that the read pointer never exceeds the allocated memory region for the packet. This change ensures that even if a malicious server sends an ERROR packet without a null terminator or with insufficient data length, the loop will terminate safely at the end of the valid buffer rather than continuing into adjacent heap space. Additionally, implementing strict validation of the payload length against the expected maximum error string size before initiating the copy operation would provide defense in depth. Regular security audits and static analysis tools configured to detect out-of-bounds reads should be employed during development to prevent similar issues in other network protocol implementations within the NetX Duo stack.