Vulnerability · Published Sep 29, 2026 · Assigned by eclipse
CVE-2026-102758
High 7.5
In plain English
A high-severity security flaw in NetX Duo from Eclipse Foundation. There are no confirmed reports of exploitation so far. The chance it is exploited in the next 30 days is estimated at 0.2% (higher than 7% of all known vulnerabilities).
Official description
The `_nx_secure_x509_asn1_tlv_block_parse()` function parses ASN.1 TLV (tag-length-value) blocks out of DER-encoded data. It is the primitive underneath all X.509 certificate parsing in NetX Secure, and therefore runs on certificates supplied by a remote peer during the TLS handshake. The function reads the one-byte ASN.1 tag from the caller's buffer *before* checking that the buffer holds at least one byte. When a caller passes a remaining length of zero, the guard correctly returns `NX_SECURE_X509_ASN1_LENGTH_TOO_LONG`, but the read has already happened one byte past the end of the buffer. code: nx_secure/src/nx_secure_x509_asn1_tlv_block_parse.c ``` UINT _nx_secure_x509_asn1_tlv_block_parse(const UCHAR *buffer, ULONG *buffer_length, USHORT *tlv_type, USHORT *tlv_tag_class, ULONG *tlv_length, const UCHAR **tlv_data, ULONG *header_length) { UINT current_index; USHORT current_tag; ULONG length; ULONG length_bytes; current_index = 0; current_tag = buffer[current_index]; /* <-- read before the bounds check */ if (*buffer_length < 1) { return(NX_SECURE_X509_ASN1_LENGTH_TOO_LONG); } ``` The remainder of the function is correctly ordered. The multi-byte length path is guarded by `length_bytes > 4 || length_bytes > *buffer_length` before its read loop, the decoded value is checked against `length > *buffer_length`, and the second single-byte length read follows its own `*buffer_length < 1` guard. The tag read is the only load placed ahead of its check.
Affected products (as reported)
| Vendor | Product | Versions |
|---|---|---|
| Eclipse Foundation | NetX Duo | 0 – through 6.5.1.202602 |
Weakness: CWE-126 · Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H