CVE-2026-102713

Out-of-bounds write via the TLS 1.3 handshake message cache in NetX Duo in Eclipse ThreadX NetX Duo 6.5.1.202602 allows a handshake message larger than the cache to write past it and into the session control block, which holds pointers. A malicious or compromised server can make a TLS 1.3 client produce such a message before certificate authentication completes, so no server certificate is needed.

In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, built with BSD raw socket and IPv6 support, the IPv6 raw send path uses the destination-table entry it adds without checking that the add succeeded. When the destination table is full and an off-link destination is reached through a default router whose neighbour cache entry is unknown, sending on an IPv6 raw socket with header inclusion dereferences a NULL pointer.

In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the NetX Secure DTLS server allocates a session from its fixed session pool for the first datagram from any unrecognised address and port, before the cookie exchange, and never releases a session whose handshake stalls. A remote, unauthenticated attacker can exhaust the pool with one spoofed datagram per source.

In Eclipse ThreadX NetX Duo versions 6.4.5.202504 through 6.5.2.202603a, built with IPv6 path MTU discovery, the ICMPv6 Packet Too Big handler uses the destination-table entry it adds without checking that the add succeeded. A sender on the network can fill the destination table with Packet Too Big messages quoting new destinations, after which the next message makes the IP helper thread dereference a NULL pointer.

In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603, the NetX Secure DTLS server never compares the cookie a client returns with the one it issued, and treats any non-empty cookie as verified. A remote attacker can make the server send its full handshake flight, several kilobytes, to a forged source address, using it to reflect amplified traffic at a third party.

In Eclipse ThreadX NetX Duo up to and including 6.5.2.202603, the NetX Secure X.509 parser accepts a certificate whose signature is an empty BIT STRING and records a signature length of 0xFFFFFFFF. A remote peer can present such a certificate during the TLS handshake, before authentication, and make the device read far outside the certificate buffer during signature verification, which is expected to fault.

In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the TLS client's ServerHello parser and the DTLS client's HelloVerifyRequest parser read fields before verifying the message is long enough to contain them. A malicious server or on-path attacker can cause the client to read up to three bytes past a handshake message, potentially faulting the client on targets with memory protection.

In the FTP server of Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the first connection to a passive data port is accepted without verifying it comes from the client that requested passive mode. An unauthenticated network attacker connecting first to the predictable port receives the file an authenticated user downloads or supplies the content of the file the user uploads.

In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the PPP IPCP code parses a peer's Configure-Nak without validating each option's length. A malicious PPP peer can stall the PPP thread indefinitely with a zero-length option, taking the link down, and can read back up to four bytes of packet-buffer memory per exchange using a short address option.

In Eclipse ThreadX NetX Duo versions 6.4.0 through 6.5.2.202603a built with VLAN and SRP support, the MSRP parser uses the attribute list length from the received frame without comparing it to the packet length. An unauthenticated station on the same Layer 2 segment can send a short MSRP frame declaring a long list and make the MRP worker read far past the received packet, faulting it on targets with memory protection.