Eclipse NetX Duo CVE-2026-106464

The target must participate in a TLS handshake using NetX Duo's X.509 parser and receive a certificate from the attacker - this occurs whenever the device acts as a TLS client (connecting to an attacker-controlled server) or as a TLS server configured to request/accept client certificates. The malicious input is a certificate whose signature field is an empty ASN.1 BIT STRING (tlv_length == 0). No authentication, user interaction, or non-default setting is required because certificate parsing happens before handshake authentication completes (AV:N/AC:L/PR:N/UI:N). The principal LIMITING factor is reachability: only devices that establish TLS connections with untrusted/attacker-controllable peers are exposed, and the realistic impact is a crash/DoS rather than confidentiality or integrity loss.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remote, low-complexity, unauthenticated flaw with no special attack requirements, which is consistent with the description: malicious certificates are parsed directly from the peer during the TLS handshake, before any authentication completes. The impact is scoped as availability-only (VA:H, with VC:N/VI:N) yielding a base score of 8.7 (High). This maps cleanly to an out-of-bounds read (CWE-125) whose primary consequence is a crash/denial of service on the embedded TLS endpoint rather than data theft or code execution. Signal alignment is strong on exploitability but the input provides NO EPSS score and NO SSVC decision data, so exploitation probability cannot be quantified. KEV status is not listed (treated as NO) and no POC is referenced, so this is currently a theoretical-but-credible remote DoS, not confirmed in-the-wild activity. NOTE A CONFLICT: the input Tags include 'Information Disclosure' and 'Buffer Overflow', yet the authoritative CVSS sets VC:N (no confidentiality impact) and the root cause is an over-read (length 0xFFFFFFFF, pointer past buffer), not a write/overflow - the realistic outcome is a crash from dereferencing the out-of-bounds signature, so the 'Buffer Overflow' and 'Information Disclosure' tags overstate the demonstrated impact versus the vendor CVSS. Priority is genuine for anyone terminating or initiating TLS with NetX Duo on reachable embedded devices, but it is a reachability/availability risk, not a confidentiality or RCE emergency based on available data.

An attacker positioned as a TLS peer (e.g., a malicious server the device connects to, or a client connecting to a device acting as a TLS server) presents an X.509 certificate whose signature is an empty ASN.1 BIT STRING. During the unauthenticated handshake, NetX Duo parses the certificate, computes the signature length as tlv_length - 1 = 0xFFFFFFFF, and stores a pointer one byte past the buffer; subsequent use of that signature triggers a massive out-of-bounds read and likely crashes the device. No public exploit identified at time of analysis, but the condition is trivially reproducible from the description.