The flaw occurs when a user‑mode ThreadX module creates a thread: the Module Manager allocates one control block and a second block for the privileged kernel stack, but only the control block is released when the thread is deleted. This orphaned kernel stack remains in the module manager’s shared object pool, draining a fixed amount of memory on every delete. Over time the pool can be exhausted, preventing the creation of any kernel object or user‑mode thread, which results in a denial of service at the system level.

The vulnerability affects Eclipse ThreadX modules. In particular, any module loaded into Eclipse ThreadX that creates and deletes user‑mode threads is impacted. The issue exists for all versions of Eclipse ThreadX where the module manager uses the allocation logic described; no specific version is given, so all current and older releases should be considered vulnerable until a patch is applied.

The CVSS score of 6.8 classifies the weakness as moderate, and the EPSS score is not available, indicating limited data on exploitation frequency. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires the capability to load a user‑mode ThreadX module and execute a loop of thread creation and deletion, which is achievable from ordinary user privileges that can load modules. The attack path is local to the application; remote exploitation would require permission to load a module. While the difficulty is not trivial, the potential for resource exhaustion makes the risk significant, especially in systems that rely on high availability of ThreadX services.