NetX Duo CVE-2025-55084

The target must be running Eclipse ThreadX NetX Duo TLS (versions before 6.4.4) in a role that processes inbound TLS ClientHello messages - i.e., acting as a TLS server/endpoint with the secure TLS module enabled - and must be network-reachable by the attacker. The specific trigger is a ClientHello containing a supported_versions extension with a malformed version field that defeats the bound check in _nx_secure_tls_proc_clienthello_supported_versions_extension(). Limiting factors: devices not exposing a NetX Duo TLS listener, or those already updated to 6.4.4, are not exploitable; impact is confined to a low-confidentiality memory over-read with no confirmed integrity or availability effect, which materially caps real-world severity.

Signals are mostly consistent and point to a moderate, not urgent, priority. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes remote, unauthenticated, low-complexity reachability, but the impact is deliberately narrow: only VC:L (low confidentiality), with VI:N and VA:N - consistent with CWE-126 (buffer over-read), where an incorrect bound check lets an attacker read slightly beyond a buffer rather than corrupt memory or execute code. EPSS is low at 0.33% (24th percentile), the CVE is NOT in CISA KEV, and no public exploit code is referenced - so there is no public exploit identified at time of analysis and no evidence of active exploitation. The one friction point: CWE-126 over-reads in a network parser can sometimes also crash the stack (availability) or leak more than trivial data, yet the vendor-provided vector asserts VA:N and only VC:L - defenders relying on worst-case assumptions should verify crash behavior against the Eclipse advisory. Net: a genuine remotely-reachable flaw in a TLS server parser, but low-severity impact and no exploitation signals make it a patch-on-cycle item rather than an emergency, except for internet-exposed embedded TLS endpoints where it should be prioritized.

An attacker who can reach a device running NetX Duo's TLS server (before 6.4.4) sends a crafted TLS ClientHello whose supported_versions extension carries a malformed version-field length. Because _nx_secure_tls_proc_clienthello_supported_versions_extension() performs an incorrect bound check, parsing reads past the intended buffer, potentially disclosing adjacent memory contents in the handshake path. No authentication or user interaction is required (AV:N/PR:N/UI:N), though no public exploit code exists yet.