ThreadX- und NetX-Duo-Schwachstellen nach Version (ehemals Azure RTOS)

Wie viele CVEs führt die NVD für meine ThreadX- und NetX-Duo-Version?

Gezählt sind CVEs, deren NVD-Konfiguration die Version als verwundbar führt, abgefragt am 23.10.2026 über die NVD-API, ohne zurückgezogene Einträge. NVD führt die Komponenten unter zwei Namen: dem aktuellen der Eclipse Foundation, cpe:2.3:a:eclipse:threadx und cpe:2.3:a:eclipse:threadx_netx_duo, und dem älteren von Microsoft, cpe:2.3:o:microsoft:azure_rtos_threadx und cpe:2.3:o:microsoft:azure_rtos_netx_duo. Gezählt ist die Vereinigung beider.

Die Zahl ist eine Untergrenze. Die CVEs aus den Advisories vom Herbst 2026 haben in der NVD noch keine Konfiguration; der nächste Abschnitt zählt sie.

$ 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

Welche Lücken in 6.4.0 sind die schwersten?

Die Tabelle zeigt die CVEs mit CVSS ab 7,0, die NVD für NetX Duo 6.4.0 und ThreadX 6.4.0 führt, mit der Version, ab der NVD sie als korrigiert führt. Die übrigen zehn liegen zwischen 5,3 und 6,5, überwiegend Leselücken im IP-Empfang und in TLS bei NetX Duo, dazu zwei ThreadX-Lücken im Umgang mit Modulen und eine in der OSEK-Schicht.

Viele sitzen in Teilen, die nicht jede Firmware baut. HTTP-Server und -Client, DHCP und SNMP liegen bei NetX Duo im Ordner addons, TLS in nx_secure.

Warum fehlen die ThreadX-Lücken vom Herbst 2026 in der NVD-Versionsabfrage?

Zwischen Ende September und Mitte Oktober 2026 hat die Eclipse Foundation als CNA Dutzende CVEs für ThreadX, NetX Duo, USBX, FileX und GUIX veröffentlicht. In der NVD stehen sie am 23.10.2026 ohne CPE-Konfiguration, Status „Awaiting Analysis“ oder „Deferred“. Eine Versionsabfrage findet keine davon; ThreadX ab 6.4.5 zeigt in der NVD deshalb null CVEs.

Nach den Versionsbereichen in den Advisories des Projekts betreffen ThreadX 6.4.0 neun dieser CVEs, alle im Module Manager (laut Release Notes nicht erreichbar, wo der Module Manager nicht benutzt wird), und NetX Duo 6.4.0 19.

Sieben weitere CVEs zum HTTP-Server von NetX Duo und zu FileX hat NVD nur unter den Paketnamen von ST konfiguriert, etwa cpe:2.3:a:st:x-cube-azrtos-h7:3.3.0, nicht unter NetX Duo. Wer nur nach NetX Duo fragt, findet sie nicht; CVE-2024-45064 (FileX) hat bei der NVD 9,8.

Diese Einträge nennen je Paket genau eine Version: X-CUBE-AZRTOS-F4, -F7 und -G0 1.1.0, X-CUBE-AZRTOS-G4, -L4, -L5, -WB und -WL 2.0.0, X-CUBE-AZRTOS-H7 3.3.0 und X-CUBE-AZRT-H7RS 1.0.0, jeweils sieben CVEs. Für X-CUBE-AZRTOS-H7 3.5.0 zählt NVD unter dem Paketnamen null, obwohl darin NetX Duo 6.4.0 mit seinen 19 NVD-CVEs steckt.

$ 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

Welche ThreadX-Version steckt in STM32Cube?

ST liefert ThreadX und NetX Duo in seinen Cube-Paketen mit. Die aktuellen Pakete für U5, H5, WBA, N6, C0, WB und H7 enthalten 6.4.0 vom Januar 2024, ohne die Korrekturen aus 6.4.1 bis 6.5.2. Die X-CUBE-AZRTOS-Pakete für die übrigen Serien sind älter. Gelesen aus tx_api.h und nx_api.h am jeweils neuesten Tag auf 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

Hat ST die Korrekturen zurückportiert?

Die neueren Cube-Pakete holen ThreadX und NetX Duo als Submodul aus den Repositories stm32-mw-threadx und stm32-mw-netxduo von ST. Deren neueste Stände heißen v6.4.0_260327 und v6.4.0_260415. Einen Stand über 6.4.0 gibt es dort am 23.10.2026 nicht.

Die Änderungsliste st_readme.txt nennt seit dem Wechsel auf 6.4.0 nur eine Treibereinstellung, ein Dokument zur Sicherheitseinstufung, einen entfernten WLAN-Treiber und die Liste lizenzierter Chips. Die Quelldateien der Funktionen, die die Advisories zu CVE-2025-55086, CVE-2025-55081 und CVE-2025-55094 nennen, sind bei ST identisch mit Eclipse 6.4.0 (gleicher Git-Hash) und weichen von 6.5.2.202603a ab. Die Korrekturen aus 6.4.4 fehlen also auch im neuesten Stand von ST.

$ 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

Welche ThreadX-Versionen pflegt das Projekt?

SECURITY.md im Repository von ThreadX nennt als unterstützt nur 6.5.x und schreibt: „Eclipse ThreadX publishes a release every quarter. There are no long-term support branches or backports to older releases.“ Kritische Korrekturen erscheinen als Hotfix-Release, etwa NetX Duo 6.5.2.202603a.

Wie komme ich von 6.4.0 weg, und was grenze ich bis dahin ein?

Der Weg aus 6.4.0 führt über die Eclipse-Repositories. ThreadX 6.5.2.202603 bringt Ports für Cortex-M0, M3, M4, M7, M23, M33, M52, M55 und M85 mit, für Cortex-M33 jeweils für AC6, GNU und IAR.

Bis das Update im Gerät ist, lässt sich ein Teil der Lücken im Build eingrenzen. Wer IPv6 nicht braucht, setzt NX_DISABLE_IPV6 in nx_user.h. Dann fehlt der IPv6-Code im Build, darunter _nx_icmpv6_validate_options() (CVE-2025-55094) und die Verarbeitung von „Packet Too Big“ (CVE-2025-55102). In der Vorlage nx_user_sample.h ist das Makro auskommentiert, IPv6 ist also an.

Ob DHCPv6-Client, TLS-Server oder HTTP-Server überhaupt gelinkt sind, zeigt die Symboltabelle des ELF: _nx_dhcpv6_process_server_duid steht für CVE-2025-55086, _nx_secure_tls_process_clienthello für CVE-2025-55081. Fehlt die Funktion, ist der Code nicht im Image.

Wo steht die ThreadX-Version in meiner Firmware?

Im Quellcode steht die Version in common/inc/tx_api.h (THREADX_MAJOR_VERSION, THREADX_MINOR_VERSION, THREADX_PATCH_VERSION, ab 6.4.x auch THREADX_BUILD_VERSION) und für NetX Duo in common/inc/nx_api.h (NETXDUO_MAJOR_VERSION und so weiter).

Einen Versionstext gibt es in der Port-Datei: _tx_version_id in ports/<CPU>/<Toolchain>/inc/tx_port.h, etwa „ThreadX Cortex-M4/GNU Version 6.4.0“, für NetX Duo _nx_version_id in nx_port.h. Kein Code der Bibliothek verweist auf diesen Text. Entfernt der Linker ungenutzte Daten (armlink standardmäßig, GNU ld mit --gc-sections), fehlt er im Build. Dann zeigen die Funktionsnamen wie _tx_thread_create oder _nx_ip_create in der Symboltabelle des ELF, dass die Bibliothek gelinkt ist, und die Version kommt aus den Headern im Projekt.

Wie prüfe ich das von Hand?

1. 1

   Version lesen: strings -a firmware.elf | grep -E "ThreadX|NetX Duo", im Projekt aus tx_api.h und nx_api.h.

2. 2

   Prüfen, welche Komponenten gelinkt sind: arm-none-eabi-nm firmware.elf | grep -E "_tx_|_nx_|_fx_|_ux_".

3. 3

   Die betroffenen Funktionen suchen: arm-none-eabi-nm firmware.elf | grep -E "_nx_dhcpv6_process_server_duid|_nx_secure_tls_process_clienthello|_nx_icmpv6_validate_options".

4. 4

   NVD abfragen mit beiden Namen, eclipse:threadx und microsoft:azure_rtos_threadx (für NetX Duo entsprechend), und bei einem ST-Paket zusätzlich mit dem Paketnamen, etwa st:x-cube-azrtos-h7.

5. 5

   Die Security Advisories der Repositories eclipse-threadx/threadx und eclipse-threadx/netxduo gegen Ihre Version lesen: sie enthalten die CVEs, die in der NVD noch fehlen.

6. 6

   Prüfen, welche Teile Sie nutzen: der Module Manager bei ThreadX, HTTP-Server, DHCP, DNS, TLS oder FTP bei NetX Duo.

7. 7

   Den KEV-Katalog der CISA auf aktiv ausgenutzte Lücken prüfen.

Geht das auch automatisch?

LegacyMind liest aus dem Build das RTOS, den Netzwerk-Stack und weitere Bibliotheken mit ihren Versionen und gleicht jede gegen die Schwachstellenquellen ab, mit der Fundstelle im Build. Belegt das Binary keine Version, bleibt das Feld leer.