Multiple vulnerabilities in Eclipse ThreadX

“Why don’t you pick on projects your own size,
quit tormenting the tiny ones!”
— The Grugq


Azure RTOS was Microsoft’s real-time operating system for IoT devices. At the beginning of 2024, Microsoft contributed the Azure RTOS technology to the Eclipse Foundation. With the Eclipse Foundation as its new home, Azure RTOS was rebranded as Eclipse ThreadX.

Eclipse ThreadX is an advanced embedded development suite including a small but powerful operating system that provides reliable, ultra-fast performance for resource-constrained devices. It offers a vendor-neutral, open source, safety certified OS for real-time applications, all under a permissive license.

I reviewed ThreadX’s source code hosted on GitHub and identified multiple security vulnerabilities that may cause memory corruption. Their impacts range from denial of service to potential arbitrary code execution.

My detailed advisory is available at


Continuing my recent vulnerability research work in the IoT space, I keep assisting open-source projects in finding and fixing security vulnerabilities by reviewing their source code. In December 2023, Azure RTOS, which one month later was rebranded as Eclipse ThreadX, was selected as a target of interest.

During the source code review, as usual, I used my Semgrep C/C++ ruleset and weggli pattern collection to identify hotspots in code on which to focus my attention.


Following my source code review, I reported 8 bugs across 4 repositories. The resulting vulnerabilities are:

  • CVE-2024-2214 – Ineffective array size check and static buffer overflow in Eclipse ThreadX
  • CVE-2024-2212 – Integer wraparounds, under-allocations, and heap buffer overflows in in Eclipse ThreadX
  • CVE-2024-2452 – Integer wraparound, under-allocation, and heap buffer overflow in Eclipse ThreadX NetX Duo
  • Other bugs with potential security implications in Eclipse ThreadX NetX Duo and USBX

For additional information about these vulnerabilities and their fixes, please refer to the detailed advisory.

It took me about 24 hours to complete the code review, with an additional 24 hours spent in the disclosure process, which got a bit complicated due to the ongoing project ownership transfer (see below).

Disclosure and fixes

I reported the vulnerabilities discussed in this article to Microsoft in December 2023 and early January 2024, via their MSRC Researcher Portal. For my efforts, I was awarded 7th place in the Top MSRC 2023 Q4 Azure Security Researchers Leaderboard.

Researcher Portal Azure Leaderboard rankings
I’d like to thank the Academy!

Following the project ownership transfer to the Eclipse Foundation, with Microsoft’s help, I coordinated with the new maintainers to provide vulnerability information and fixes to the ThreadX users’ community. Eclipse ThreadX maintainers have fixed all vulnerabilities discussed in this article.

The (simplified) coordinated disclosure timeline follows:

  • 2023-12-01: Reported two vulnerabilities to MSRC.
  • 2023-12-13: MSRC confirmed our first vulnerability.
  • 2023-12-14: MSRC confirmed our second vulnerability.
  • 2023-12-21: Reported other two vulnerabilities to MSRC.
  • 2023-12-31: Reported another vulnerability to MSRC.
  • 2024-01-02: Reported other three vulnerabilities to MSRC.
  • 2024-01-05: MSRC confirmed a vulnerability was fixed in version 6.4.
  • 2024-01-06: MSRC informed us we made the 2023 Q4 leaderboard!
  • 2024-01-10: MSRC confirmed another vulnerability was fixed in version 6.4.
  • 2024-02-10: Asked MSRC for updates on all open reports.
  • 2024-02-16: Asked the Eclipse Foundation for advice on how to proceed.
  • 2024-02-20: Eclipse replied they were coordinating with MSRC.
  • 2024-02-21: MSRC informed us of the ownership transfer to Eclipse.
  • 2024-02-27: MSRC confirmed a third vulnerability was fixed in version 6.4.
  • 2024-02-28: Upon MSRC’s request, we submitted our reports to Eclipse.
  • 2024-03-05: Eclipse started creating GitHub advisories for all reports.
  • 2024-03-13: Provided Eclipse with clarifications on some of the reports.
  • 2024-03-15: MSRC provided some additional feedback on the transition.
  • 2024-03-18: Eclipse finished creating GitHub advisories for all reports.
  • 2024-03-22: MSRC closed the remaining cases after the transition.
  • 2024-03-25: Eclipse published CVE-2024-2212, CVE-2024-2214, CVE-2024-2452.
  • 2024-03-29: Provided Eclipse with clarifications on remaining reports.
  • 2024-04-24: Asked for a status update on the remaining reports.
  • 2024-04-26: Agreed to declass the remaining reports to standard issues.
  • 2024-05-02: Sent draft advisory and writeup to MSRC and Eclipse.
  • 2024-05-28: Published advisory and writeup.

Please check the official Eclipse ThreadX channels for further information about fixes.


I would like to thank MSRC and the Eclipse Foundation (with a special mention to Marta Rybczynska who took care of coordinated disclosure after the project ownership change) for triaging and fixing the reported vulnerabilities. It was a pleasure to work with you!