NetX Duo CVE-2026-114408

Exploitation requires the target to be built with BOTH FEATURE_NX_IPV6 and NX_ENABLE_IPV6_PATH_MTU_DISCOVERY; path MTU discovery is disabled by default and builds without it do not compile the vulnerable code, so this is the single most important limiting factor. Releases up to and including 6.4.4.202503a predate the introducing fix (CVE-2025-55102) and are not affected. The attacker must send at least NX_IPV6_DESTINATION_TABLE_SIZE + 1 ICMPv6 Packet Too Big messages quoting distinct destinations (9 with the default table of 8, 33 with a table of 32); the handler checks neither the source address nor the hop limit and accepts any reported MTU greater than zero up to the interface MTU. The crash (SIGSEGV) is confirmed only on targets that fault on address 0 - on platforms where memory near address 0 is readable the dereference does not fault and the outcome is unverified. Measured exploitation was from a link-local sender on the same link.

This is a genuine but conditional availability risk, not a mass-exploitation emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes an unauthenticated, low-complexity, network-reachable trigger with no user interaction, and the impact is availability-only (VA:H) - a crash of the IP helper thread that halts all network processing. However, raw CVSS overstates real-world exposure here because the vulnerable code is compiled only in builds with both FEATURE_NX_IPV6 and NX_ENABLE_IPV6_PATH_MTU_DISCOVERY, and path MTU discovery is OFF by default per the Eclipse advisory, so default builds are not affected at all. No EPSS score and no KEV listing are present in the input, and there is no confirmed public exploit; the only working trigger described is Eclipse's own internal regression test. The vuln.today decision label is 'this_week', consistent with a real but prioritizable issue rather than act_now/emergency. Note also a scope caveat the evidence states explicitly: the crash only occurs on targets that fault on address 0 - on targets where memory near address 0 is readable the SIGSEGV does not occur and that path was not measured, so impact is platform-dependent. The CVSS AV:N should be read against the measured reality that the proof-of-concept traffic came from a link-local sender on the same link; wider remote reachability of ICMPv6 Packet Too Big messages depends on network topology.

An attacker able to send ICMPv6 Packet Too Big messages to an affected device (measured from a link-local sender on the same link) emits a sequence of such messages each quoting a distinct new destination, filling the IPv6 destination table (8 entries by default). The next Packet Too Big message causes the handler to use a NULL entry returned by a failed table add, dereferencing it in the IP helper thread and crashing network processing on targets that fault on address 0. No public exploit is identified at time of analysis; Eclipse's regression test netx_icmpv6_packet_too_big_table_full_test reproduces the SIGSEGV in 9 of 9 runs but is not published exploit code.