Eclipse ThreadX

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 4 Last 12 months 7 Lifetime Memory safety 45 % Parsing/validation 30 % Privilege escalation 15 % Info disclosure 10 % Latest advisories Loading the feed Overview Eclipse ThreadX is the RTOS Microsoft shipped as Azure RTOS before donating it to the Eclipse Foundation, and Microsoft put its deployment at more than twelve billion devices at the time of the handover. ST, Renesas, NXP and Microchip all ship it inside their MCU stacks alongside the NetX networking and FileX filesystem components, and it runs in medical devices, automotive ECUs and industrial controllers. Those are products flashed once at the factory and rarely updated again, so a defect stays exploitable for the service life of the hardware. The donation moved it off Microsoft's bounty surface and the Eclipse process pays nothing, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The Eclipse Foundation vulnerability reporting policy accepts security issues in any Eclipse project, and the ThreadX repositories enable GitHub private vulnerability reporting for exactly that. No ThreadX-specific carve-out appears in the research behind this entry, so the whole eclipse-threadx tree is the declared target The ThreadX kernel: thread scheduling, preemption-threshold handling, mutexes and their priority inheritance, semaphores, event flags, message queues and the byte and block memory pools The module manager and its memory protection, where a loadable module is meant to stay isolated from the kernel NetX Duo end to end, covering the IPv4 and IPv6 stacks, TCP, UDP, ICMP and the ARP and neighbour-discovery layers, all of which parse frames straight off the wire The NetX Duo application protocols shipped in the tree: DHCP, DNS, mDNS, the HTTP and HTTPS servers and clients, MQTT, SNTP, SNMP, FTP, TFTP, PPP, SMTP and Telnet NetX Secure, the TLS and DTLS implementation, including handshake state handling, certificate parsing and X.509 verification FileX with its FAT and exFAT implementations, plus LevelX and the NAND and NOR flash wear-levelling layers beneath it USBX host, device and OTG stacks, including every device class that parses descriptors from the other end of the cable GUIX and its rendering and resource-parsing paths, where a display resource may come from storage an attacker has touched The processor ports and the low-level context switch and interrupt entry code, where a defect is specific to one architecture Out of scope Silicon vendor SDK forks. ST, Renesas, NXP and Microchip ship their own integrations, and a defect that exists only there belongs to that vendor Azure RTOS releases predating the Eclipse donation, along with Microsoft's own downstream products built on them Application code that misuses a ThreadX API in a way the documentation warns against Integrator configuration choices, such as building without the module manager's memory protection enabled Findings against a third-party network stack or filesystem an integrator substituted for the ones in the tree Physical attacks on a device an attacker already holds, including debug-port readout of flash Most-valued findings Memory corruption in NetX Duo's packet handling, reachable from the network before any application logic runs, on devices that frequently sit on a flat clinical or industrial network with no segmentation Defects in NetX Secure TLS and DTLS, especially certificate chain verification and handshake state handling, since that is the only thing between the device and an active network attacker Parsing bugs in the bundled application protocols, particularly the HTTP and MQTT servers and the DHCP and DNS clients, all of which read attacker-controlled input by design Module manager escapes, where a loadable module reaches kernel memory the protection scheme was supposed to deny it Kernel primitives that can be driven into an inconsistent state: priority inheritance, queue and pool management, and anything reachable from interrupt context FileX and exFAT parsing reached from removable media or an update image, with LevelX flash metadata handling underneath it USBX descriptor and class-driver parsing, reachable by anyone who can plug something into the device for a moment Anything that survives a reset or writes to flash, since a large share of these products have no field update mechanism at all Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through GitHub private vulnerability reporting on the affected eclipse-threadx repository, which the project enables, or through the Eclipse Foundation vulnerability reporting process Do not open a public GitHub issue for a security defect Name the component. ThreadX the kernel, NetX Duo the network stack, FileX the filesystem, LevelX, USBX and GUIX are separate repositories under the same organisation, and a defect usually sits in exactly one State the architecture, the port and the toolchain you reproduced on. ThreadX ships a port per core and some defects only exist in the low-level context switch or interrupt code of one Do not route this to Microsoft. The donation to Eclipse moved ThreadX off the MSRC bounty surface, and no Microsoft or Eclipse programme covering it appears on any bounty platform If the defect exists only in a silicon vendor's integration rather than in the upstream tree, take it to that vendor instead The Eclipse Foundation runs a coordinated-disclosure process rather than a bounty, so there is no payment to negotiate upstream Disclosure Coordinated with the Eclipse Foundation security team through a GitHub private vulnerability report or the Foundation's own intake, and published as a GitHub Security Advisory alongside a fix in the tree. The pipeline is modest in volume, four advisories in the last year against seven ever published, so triage is unlikely to be instant. A fix then has to cross the silicon vendor's SDK and the device maker before it reaches hardware, so hold detail until the advisory is public and expect the field exposure to outlast it by years. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability