---
id: "CVE-2026-92853"
kind: "vulnerability"
aliases: ["CVE-2026-92853"]
title: "NetX Secure: zero-length TLS certificate message reads past packet buffer"
severity: "high"
cvss: 8.7
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: [{"name": "NetX Duo (Eclipse ThreadX)", "fixed": ["6.5.2.202603"], "affected": "<= 6.5.1.202602", "ecosystem": "vendor"}]
ecosystems: []
tags: ["azure-rtos", "dos", "dtls", "eclipse-threadx", "embedded", "infrastructure", "iot", "netx-duo", "netx-secure", "tls-1.3"]
not_affected_if: ["no-tls-1.3-server", "not-netx-secure", "tls-1.3-disabled"]
published_at: "2026-10-20T16:17:17+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-24T00:12:40+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92853", "first_seen_at": "2026-10-23T21:57:20+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-24T00:12:40+00:00"}]
---

# NetX Secure: zero-length TLS certificate message reads past packet buffer

NetX Secure's TLS 1.3 Certificate parser decrements message_length without checking it, so a zero-length Certificate message wraps to 0xFFFFFFFF and defeats the bounds check. A malicious TLS 1.3 server or on-path attacker can crash a connecting NetX Duo client before authentication. The same code is reached by servers that verify client certificates and by DTLS 1.3 clients. On embedded targets the over-read typically causes a hard fault or reset. The vendor says the bytes read stay inside the DER parser, so there is no direct disclosure path, and it does not describe code execution.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:NetX Duo (Eclipse ThreadX) affected <= 6.5.1.202602 fixed 6.5.2.202603

## How to check

You are affected if your firmware uses Eclipse ThreadX NetX Duo <= 6.5.1.202602 with NetX Secure TLS 1.3 enabled (NX_SECURE_TLS_TLS_1_3_ENABLED). This applies to clients, to servers with client-certificate verification, and to DTLS 1.3 clients. Check the NetX Duo version in your source tree or SDK and look for _nx_secure_tls_process_remote_certificate without a message_length > 0 check before the decrement.

## Fix

Upgrade NetX Duo to 6.5.2.202603 and rebuild and reflash the firmware. The only workaround is building without TLS 1.3 support; there is none inside a TLS 1.3 build.

## Timeline

- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-92853
- 2026-10-24T00:12:40+00:00 analyst — Read vendor GHSA-893m-9g4r-4992 (Eclipse ThreadX): impact is DoS (hard fault/reset), not code execution or disclosure; fixed in 6.5.2.202603. No exploitation or public PoC found; did not search social.

## Documents

- [advisory] GHSA-893m-9g4r-4992: Out-of-bounds Read via zero-length TLS 1.3 Certificate message in NetX Secure https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-893m-9g4r-4992
- [fix] eclipse-threadx/netxduo releases (6.5.2.202603) https://github.com/eclipse-threadx/netxduo/releases

## From the sources

The TLS 1.3 Certificate-message parser in NetX Secure decrements the message length to skip a context byte without first establishing that the message has a byte to skip. A zero-length Certificate message therefore wraps the unsigned length to `0xFFFFFFFF`, which makes the bounds check that follows vacuous and sends the parser reading past the session packet buffer.



The trigger is a four-byte handshake header and requires no cryptographic validity. It is reachable pre-authentication.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_