ThreadX and NetX Duo vulnerabilities by version (formerly Azure RTOS)

How many CVEs does the NVD list for my ThreadX and NetX Duo versions?

Counted are CVEs whose NVD configuration lists the version as vulnerable, queried on 23 October 2026 through the NVD API, rejected entries excluded. The NVD lists the components under two names: the current Eclipse Foundation one, cpe:2.3:a:eclipse:threadx and cpe:2.3:a:eclipse:threadx_netx_duo, and the older Microsoft one, cpe:2.3:o:microsoft:azure_rtos_threadx and cpe:2.3:o:microsoft:azure_rtos_netx_duo. The count is the union of both.

The number is a lower bound. The CVEs from the advisories of autumn 2026 have no NVD configuration yet; the next section counts them.

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:eclipse:threadx_netx_duo:6.4.0&noRejected"  \
| jq .totalResults

19

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:eclipse:threadx:6.4.0&noRejected"  \
| jq .totalResults

4

Which vulnerabilities in 6.4.0 are the most severe?

The table shows the CVEs with CVSS 7.0 or higher that the NVD lists for NetX Duo 6.4.0 and ThreadX 6.4.0, with the version from which the NVD lists them as fixed. The other ten range from 5.3 to 6.5, mostly read flaws in NetX Duo's IP receive path and TLS, plus two ThreadX flaws in module handling and one in the OSEK layer.

Many sit in parts not every firmware builds. In NetX Duo, the HTTP server and client, DHCP and SNMP live in the addons folder, TLS in nx_secure.

Why does the NVD version query miss the autumn 2026 ThreadX vulnerabilities?

Between late September and mid-October 2026 the Eclipse Foundation as CNA published dozens of CVEs for ThreadX, NetX Duo, USBX, FileX and GUIX. On 23 October 2026 they are in the NVD without a CPE configuration, status “Awaiting Analysis” or “Deferred”. No version query finds them; ThreadX from 6.4.5 on therefore shows zero CVEs in the NVD.

By the version ranges in the project's advisories, nine of these CVEs affect ThreadX 6.4.0, all in the Module Manager (not reachable where the Module Manager is not used, according to the release notes), and 19 affect NetX Duo 6.4.0.

Seven further CVEs on the NetX Duo HTTP server and on FileX are configured by the NVD only under ST's package names, for example cpe:2.3:a:st:x-cube-azrtos-h7:3.3.0, not under NetX Duo. Asking for NetX Duo alone does not find them; CVE-2024-45064 (FileX) is 9.8 at the NVD.

These entries name exactly one version per package: X-CUBE-AZRTOS-F4, -F7 and -G0 1.1.0, X-CUBE-AZRTOS-G4, -L4, -L5, -WB and -WL 2.0.0, X-CUBE-AZRTOS-H7 3.3.0 and X-CUBE-AZRT-H7RS 1.0.0, seven CVEs each. For X-CUBE-AZRTOS-H7 3.5.0 the NVD counts zero under the package name, although it contains NetX Duo 6.4.0 with its 19 NVD CVEs.

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:st:x-cube-azrtos-h7:3.3.0&noRejected"  \
| jq .totalResults

7

Which ThreadX version is in STM32Cube?

ST ships ThreadX and NetX Duo in its Cube packages. The current packages for U5, H5, WBA, N6, C0, WB and H7 contain 6.4.0 of January 2024, without the fixes from 6.4.1 to 6.5.2. The X-CUBE-AZRTOS packages for the other series are older. Read from tx_api.h and nx_api.h at the newest tag on GitHub:

$ curl -s https://raw.githubusercontent.com/STMicroelectronics/x-cube-azrtos-h7/v3.5.0/Middlewares/ST/netxduo/common/inc/nx_api.h  \
| grep -E "define NETXDUO_(MAJOR|MINOR|PATCH)_VERSION"

#define NETXDUO_MAJOR_VERSION                    6
#define NETXDUO_MINOR_VERSION                    4
#define NETXDUO_PATCH_VERSION                    0

Has ST backported the fixes?

The newer Cube packages pull ThreadX and NetX Duo as submodules from ST's repositories stm32-mw-threadx and stm32-mw-netxduo. Their newest states are called v6.4.0_260327 and v6.4.0_260415. On 23 October 2026 there is nothing above 6.4.0 there.

The change list st_readme.txt names, since the move to 6.4.0, only a driver setting, a document on the security classification, a removed WiFi driver and the list of licensed chips. The source files of the functions named in the advisories for CVE-2025-55086, CVE-2025-55081 and CVE-2025-55094 are identical at ST and in Eclipse 6.4.0 (same Git hash) and differ from 6.5.2.202603a. The fixes from 6.4.4 are therefore missing from ST's newest state too.

$ for r in STMicroelectronics/stm32-mw-netxduo@v6.4.0_260415  \
eclipse-threadx/netxduo@v6.4.0_rel  \
eclipse-threadx/netxduo@v6.5.2.202603a_rel;  \
do echo "$r $(gh api "repos/${r%@*}/contents/addons/dhcp/nxd_dhcpv6_client.c?ref=${r#*@}" -q .sha)";  \
done

STMicroelectronics/stm32-mw-netxduo@v6.4.0_260415 e88bf5500a52822d6903a65dd32014415c399774
eclipse-threadx/netxduo@v6.4.0_rel e88bf5500a52822d6903a65dd32014415c399774
eclipse-threadx/netxduo@v6.5.2.202603a_rel a303075d04ca4a1b0b1c868d3183488edd05a7e8

Which ThreadX versions does the project maintain?

SECURITY.md in the ThreadX repository lists only 6.5.x as supported and says: “Eclipse ThreadX publishes a release every quarter. There are no long-term support branches or backports to older releases.” Critical fixes ship as hotfix releases, such as NetX Duo 6.5.2.202603a.

How do I move off 6.4.0, and what do I narrow down until then?

The way out of 6.4.0 runs through the Eclipse repositories. ThreadX 6.5.2.202603 ships ports for Cortex-M0, M3, M4, M7, M23, M33, M52, M55 and M85, for Cortex-M33 each for AC6, GNU and IAR.

Until the update is in the device, part of the exposure can be narrowed in the build. If you do not need IPv6, set NX_DISABLE_IPV6 in nx_user.h. The IPv6 code then drops out of the build, including _nx_icmpv6_validate_options() (CVE-2025-55094) and the “Packet Too Big” handling (CVE-2025-55102). In the template nx_user_sample.h the macro is commented out, so IPv6 is on.

Whether the DHCPv6 client, TLS server or HTTP server is linked at all shows in the ELF symbol table: _nx_dhcpv6_process_server_duid stands for CVE-2025-55086, _nx_secure_tls_process_clienthello for CVE-2025-55081. If the function is missing, the code is not in the image.

Where is the ThreadX version in my firmware?

In the source the version sits in common/inc/tx_api.h (THREADX_MAJOR_VERSION, THREADX_MINOR_VERSION, THREADX_PATCH_VERSION, from 6.4.x also THREADX_BUILD_VERSION) and for NetX Duo in common/inc/nx_api.h (NETXDUO_MAJOR_VERSION and so on).

A version string exists in the port file: _tx_version_id in ports/<CPU>/<toolchain>/inc/tx_port.h, for example “ThreadX Cortex-M4/GNU Version 6.4.0”, and for NetX Duo _nx_version_id in nx_port.h. No library code references this string. If the linker removes unused data (armlink by default, GNU ld with --gc-sections), it is missing from the build. Then function names such as _tx_thread_create or _nx_ip_create in the ELF symbol table show that the library is linked, and the version comes from the headers in the project.

How do I check this by hand?

1. 1

   Read the version: strings -a firmware.elf | grep -E "ThreadX|NetX Duo"; in the project from tx_api.h and nx_api.h.

2. 2

   Check which components are linked: arm-none-eabi-nm firmware.elf | grep -E "_tx_|_nx_|_fx_|_ux_".

3. 3

   Look for the affected functions: arm-none-eabi-nm firmware.elf | grep -E "_nx_dhcpv6_process_server_duid|_nx_secure_tls_process_clienthello|_nx_icmpv6_validate_options".

4. 4

   Query the NVD with both names, eclipse:threadx and microsoft:azure_rtos_threadx (likewise for NetX Duo), and for an ST package also with the package name, for example st:x-cube-azrtos-h7.

5. 5

   Read the security advisories of the repositories eclipse-threadx/threadx and eclipse-threadx/netxduo against your version: they contain the CVEs still missing from the NVD.

6. 6

   Check which parts you use: the Module Manager in ThreadX; HTTP server, DHCP, DNS, TLS or FTP in NetX Duo.

7. 7

   Check the CISA KEV catalogue for actively exploited vulnerabilities.

Can this run automatically?

LegacyMind reads the RTOS, the network stack and other libraries with their versions from the build and matches each against the vulnerability sources, with the place in the build where it was read. Where the binary proves no version, the field stays empty.