{"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\n\n\n\nfour bytes (nxd_tftp_server.c:1037) and nothing anywhere checks an upper bound, in particular not\n\n\n\nagainst 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","slug":"CVE-2026-102713","body":"## Overview\n\nThe TFTP server accepts a DATA datagram of any size. The dispatcher rejects datagrams shorter than\n\n\n\nfour bytes (nxd_tftp_server.c:1037) and nothing anywhere checks an upper bound, in particular not\n\n\n\nagainst the protocol maximum of 4 + NX_TFTP_FILE_TRANSFER_MAX. Two things follow from that one\n\n\n\nmissing check, both reachable before any authentication because TFTP has none.\n\n\n\nThe handler passes `nx_packet_length - 4` straight to FileX:\n\n\n\n```c\n\n\n\n/* addons/tftp/nxd_tftp_server.c:1863, 1889 */\n\n\n\nstatus = nx_packet_copy(packet_ptr, &temp_ptr,\n\n                        server_ptr -> nx_tftp_server_packet_pool_ptr, NX_WAIT_FOREVER);\n\n\n...\n\n\n\nfx_file_write(&(client_request_ptr -> nx_tftp_client_request_file),\n\n              packet_ptr -> nx_packet_prepend_ptr + 4,\n              packet_ptr -> nx_packet_length - 4);\n\n\n```\n\n\n\n`nx_packet_length` is the length of a chain, not of one contiguous buffer, so FileX copies past the\n\n\n\nend of the first packet:\n\n\n\n```\n\n\n\nERROR: AddressSanitizer: heap-buffer-overflow\n\n\n\nREAD of size 1280 at 0x621000001108 thread T5\n\n    #0 __interceptor_memcpy\n    #1 _fx_utility_memory_copy  filex/common/src/fx_utility_memory_copy.c:78\n\n\n0x621000001108 is 0 bytes to the right of 4104-byte region\n\n\n\n```\n\n\n\nThose bytes are written into the file the attacker is uploading, and a TFTP read request hands them\n\n\n\nback, so this is a memory disclosure with a convenient retrieval channel.\n\n\n\nThe same datagram also wedges the server. `nx_packet_copy` at :1863 needs\n\n\n\nceil(nx_packet_length / pool_payload) packets and asks for them with NX_WAIT_FOREVER, so when the\n\n\n\nattacker sizes the datagram beyond what the pool holds, the server thread suspends and never\n\n\n\nreturns. A liveness probe after one such datagram times out with the pool at 0 of 12 packets and\n\n\n\nthe server thread suspended, and no later client is served.\n\n\n\nReject `nx_packet_length > 4 + NX_TFTP_FILE_TRANSFER_MAX` in the DATA branch before either call,\n\n\n\nand use a bounded wait rather than NX_WAIT_FOREVER for the copy.\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"twilight","depthScore":48,"depthScoreParts":{"impact":48.4,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}