---
id: "CVE-2026-93475"
kind: "vulnerability"
aliases: ["CVE-2026-93475"]
title: "NetX Secure: oversized RSA certificate key overflows a static buffer"
severity: "critical"
cvss: 9.3
epss: null
exploited: false
status: "open"
category: "runtime"
products: [{"name": "NetX Duo", "fixed": ["6.5.2.202603"], "affected": "<= 6.5.1.202602", "ecosystem": "vendor"}]
ecosystems: []
tags: ["client-certificate-auth", "dtls", "embedded", "netx-duo", "netx-secure", "other", "runtime", "threadx", "tls-clients", "tls-servers"]
not_affected_if: ["default-config"]
published_at: "2026-10-20T16:17:17+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-23T23:19:09+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93475", "first_seen_at": "2026-10-23T21:57:20+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-23T23:19:09+00:00"}]
---

# NetX Secure: oversized RSA certificate key overflows a static buffer

NetX Secure (Eclipse ThreadX NetX Duo) X.509 parsing accepts RSA moduli up to 64 KiB, but certificate verification decrypts into a fixed 512-byte static buffer sized for 4096 bits. A peer sends an oversized-key intermediate certificate in its own chain, which gives an attacker-influenced out-of-bounds write before authentication. It affects TLS/DTLS clients and servers that use client-certificate authentication. No exploitation path has been developed or published yet.

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

## Affected

- vendor:NetX Duo affected <= 6.5.1.202602 fixed 6.5.2.202603

## How to check

Check your NetX Duo version: it is vulnerable if it is 6.5.1.202602 or older. Any build that verifies a peer certificate chain is affected (TLS/DTLS client, or server with client-cert auth). No build option avoids the path.

## Fix

Upgrade NetX Duo to 6.5.2.202603 or later. The parser now rejects RSA moduli larger than NX_CRYPTO_MAX_RSA_MODULUS_SIZE, and _nx_crypto_method_rsa_init refuses them too. There is no workaround; disabling chain verification is not a mitigation.

## Timeline

- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-93475
- 2026-10-23T23:19:09+00:00 analyst — Read the primary GHSA-rcv5-vfff-25gh (eclipse-threadx/netxduo). Affected <= 6.5.1.202602, fixed 6.5.2.202603. The advisory says there is no workaround, so the triage idea of raising the RSA modulus limit at build time is not supported: the verify buffer is a fixed 512-byte static. No PoC or exploitation reported, and no X posts. NVD page returned empty, so CVE text came from the search snippets and the GHSA.

## Documents

- [advisory] GHSA-rcv5-vfff-25gh: Out-of-bounds Write via an Unbounded RSA Modulus in NetX Secure X.509 https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-rcv5-vfff-25gh

## From the sources

The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the `NX_CRYPTO_MAX_RSA_MODULUS_SIZE` default of 4096 bits. A certificate carrying a larger modulus drives an out-of-bounds write past a file-scope static during ordinary certificate-chain verification.



It is reachable pre-authentication. The issuer used for the crypto operation is looked up in the remote, peer-supplied store before the trusted store, so the attacker supplies the oversized key themselves as an intermediate in the chain they present. It triggers on a TLS or DTLS client verifying a malicious server's chain, and on a server performing client-certificate authentication.

---

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