CVE-2025-55082 Overview
CVE-2025-55082 is an out-of-bounds read vulnerability in Eclipse ThreadX NetX Duo before version 6.4.4. The flaw resides in the _nx_secure_tls_process_clienthello() function, which fails to validate the Pre-Shared Key (PSK) length supplied in a user-controlled TLS ClientHello message. A remote attacker can trigger the memory read by sending a crafted TLS handshake message to a vulnerable NetX Duo TLS server. The issue is classified under CWE-125 (Out-of-Bounds Read) and affects embedded and IoT devices built on the ThreadX real-time operating system.
Critical Impact
Remote, unauthenticated attackers can trigger an out-of-bounds read in the TLS handshake path, potentially leaking adjacent memory contents from embedded devices.
Affected Products
- Eclipse ThreadX NetX Duo versions before 6.4.4
- Embedded systems and IoT devices using NetX Secure TLS
- Applications relying on _nx_secure_tls_process_clienthello() with PSK cipher suites
Discovery Timeline
- 2025-10-15 - CVE-2025-55082 published to the National Vulnerability Database (NVD)
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-55082
Vulnerability Analysis
The vulnerability exists in the TLS handshake processing code within NetX Secure, a component of Eclipse ThreadX NetX Duo. The function _nx_secure_tls_process_clienthello() parses the ClientHello record sent by remote TLS peers. When the record includes a Pre-Shared Key identity extension, the code reads the PSK length field from attacker-controlled bytes and uses it without verifying that the declared length remains within the ClientHello message buffer.
An attacker who initiates a TLS connection to a vulnerable device can supply a PSK length value that exceeds the actual bounds of the received handshake buffer. The parser then reads memory beyond the intended region, producing an out-of-bounds read. Depending on device memory layout, this can cause information disclosure or destabilize the TLS session. The vulnerability is reachable pre-authentication because the ClientHello is the first message in a TLS handshake.
Root Cause
The root cause is missing input validation on the PSK length field parsed from the ClientHello message. The code trusts the length declared by the client and does not bound-check it against the remaining size of the ClientHello buffer before dereferencing subsequent bytes.
Attack Vector
Exploitation requires network access to a TLS listener running vulnerable NetX Duo code with PSK cipher suites enabled. The attacker crafts a malformed ClientHello containing an oversized PSK identity length. No credentials or user interaction are required. The vulnerability affects confidentiality of process memory adjacent to the TLS handshake buffer. See the GitHub Security Advisory GHSA-8h38-qjhh-mf2h for vendor details.
Detection Methods for CVE-2025-55082
Indicators of Compromise
- TLS ClientHello messages containing PSK identity extensions with length fields inconsistent with the record size
- Unexpected TLS handshake failures or device resets on embedded endpoints running NetX Duo
- Anomalous inbound TLS connections targeting IoT and embedded devices from untrusted sources
Detection Strategies
- Inspect TLS handshake traffic at network boundaries for malformed PSK identity extension length fields
- Enable verbose logging on NetX Secure TLS servers to capture ClientHello parsing errors
- Deploy intrusion detection signatures that flag TLS ClientHello messages where declared PSK length exceeds record boundaries
Monitoring Recommendations
- Track inbound TLS connections to embedded devices and alert on repeated handshake anomalies from the same source
- Correlate device crash telemetry with preceding TLS connection attempts to identify probing activity
- Monitor firmware inventories for NetX Duo versions below 6.4.4 across the device fleet
How to Mitigate CVE-2025-55082
Immediate Actions Required
- Upgrade Eclipse ThreadX NetX Duo to version 6.4.4 or later on all affected devices
- Identify embedded and IoT devices exposing NetX Secure TLS listeners to untrusted networks
- Restrict network reachability of TLS services on ThreadX-based devices to trusted management segments
Patch Information
Eclipse Foundation resolved the issue in NetX Duo version 6.4.4. The fix adds validation of the PSK length value against the ClientHello buffer size in _nx_secure_tls_process_clienthello(). Refer to the Eclipse ThreadX NetX Duo GitHub Security Advisory for release details and integration guidance.
Workarounds
- Disable PSK cipher suites in NetX Secure TLS configurations where feasible until firmware can be updated
- Place vulnerable devices behind a TLS-terminating proxy or firewall that enforces strict handshake validation
- Apply network access control lists to limit which hosts can initiate TLS connections to affected devices
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
