Live › vulnerability › CVE-2026-115654
In Eclipse ThreadX 6.0.1 through 6.5.2.202603, the Module Manager's thread-control services do not check that a thread belongs to the calling module. Any loaded module can suspend, resume, terminate, reset or re-prioritise other threads, causing denial of service or changing scheduling.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-02 16:24 UTC. All times on this page are UTC.
Teams building embedded or real-time systems on ThreadX with the Module Manager and more than one user-mode module loaded. Systems that use ThreadX without the Module Manager, or outside the listed versions, are not in the stated range. The sources do not say more.
No product ranges from the sources yet.
6.0.1 through 6.5.2.202603No fix yet, per the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager's thread-control services do not check that a thread passed by a user-mode, memory-protected module belongs to that module. Any loaded module can suspend, resume, terminate, reset or re-prioritise application threads and other modules' threads and abort their waits, denying service or changing how the system schedules them.
This page as .md · .json · in your agent: get_signal("CVE-2026-115654")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.