Key points
- CVE-2026-92853 carries a CVSS score of 8.7 and is rated high severity.
- The flaw resides in the TLS 1.3 Certificate-message parser within NetX Secure.
- Affected components include Eclipse ThreadX NetX Duo versions up to 6.5.1.202602.
Eclipse Foundation products containing NetX Secure are affected by a parser vulnerability that permits out-of-bounds memory access. The issue is reachable before authentication and requires no cryptographic validity to trigger.
What happened
The National Vulnerability Database records CVE-2026-92853 as a high severity vulnerability with a CVSS score of 8.7. The flaw exists within the TLS 1.3 Certificate-message parser component of NetX Secure. According to the NVD record, the parser logic decrements the message length to skip a context byte. This operation occurs without first verifying that the message contains a byte to skip.
Consequently, a zero-length Certificate message causes the unsigned length value to wrap to 0xFFFFFFFF. This wrap-around renders the subsequent bounds check ineffective. The parser then reads data past the end of the session packet buffer. The trigger mechanism consists of a four-byte handshake header. The NVD notes that this header requires no cryptographic validity. The vulnerability is reachable in a pre-authentication state. The underlying weaknesses are identified as CWE-125 and CWE-191.
Why it matters
Eclipse ThreadX NetX Duo versions up to 6.5.1.202602 are listed as affected products. Security teams using these embedded network stacks must assess their exposure. The pre-authentication nature of the flaw means unauthenticated network traffic can reach the vulnerable parser. The absence of a cryptographic requirement for the trigger lowers the barrier for exploitation. Organizations relying on NetX Secure for TLS 1.3 connections face direct risk from this parser error. The out-of-bounds read occurs because the bounds check becomes vacuous after the length wrap. This behaviour allows the parser to access memory beyond the allocated session packet buffer.
What happens next
- Identify all systems running NetX Duo versions up to 6.5.1.202602.
- Monitor Eclipse Foundation communications for any security advisories.
- Review network traffic logs for unusual TLS handshake patterns.
- Verify that no confirmed patch or update is currently available.
Patch priority
Teams usually begin by mapping all assets that include the affected NetX Secure library. It is vital to determine which systems are exposed to untrusted networks. Since no fix is confirmed, operators should focus on limiting network access to these endpoints. Check whether existing firewalls or network segmentation can block unauthorised handshake attempts. Backup current configurations before making any network changes. Monitor vendor channels closely for an official update. Prioritise systems that handle external TLS connections in pre-authentication states. Ensure logging is enabled to detect potential exploitation attempts.
What to do and how to stay safe: NetX Secure
- Audit your infrastructure to find all instances of NetX Duo up to version 6.5.1.202602.
- Restrict network access to systems running the vulnerable NetX Secure parser where possible.
- Monitor for abnormal TLS handshake activity that matches the four-byte header trigger.
- Await an official update from Eclipse Foundation before applying any unofficial workarounds.
Step-by-step guide: Patch Management: Definition, Purpose and Operational Reality
General security guidance from the AppSec Scoop newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Is there a patch available for CVE-2026-92853?
No patch or fix has been confirmed yet for this vulnerability.
What is the severity of CVE-2026-92853?
The vulnerability is rated high severity with a CVSS score of 8.7.
Which versions of NetX Duo are affected?
Versions up to 6.5.1.202602 of Eclipse ThreadX NetX Duo are affected.
