Eclipse ThreadX CVE-2026-115654

Exploitation requires the system to use the Module Manager AND to load modules with memory protection (affected on every module port); the attacker must already control a loaded user-mode memory-protected module (malicious or compromised). Given that, no further special configuration is needed - the vulnerable dispatchers (tx_thread_suspend, resume, terminate, reset, priority_change, preemption_change, time_slice_change, wait_abort) accept any live thread pointer outside the calling module by default because they only validate the pointer names a live thread, not ownership. Limiting factors that reduce real-world risk: the vector is local (on-device) only, it needs pre-existing low-privilege code execution inside a loaded module, it applies only to deployments using the Module Manager with memory-protected modules, modules loaded without memory protection are unaffected (and are already unisolated), and only versions 6.0.1 through 6.5.2.202603 are vulnerable (fixed in 6.5.2.202603b). Note tx_thread_reset is limited to other modules' threads, and tx_thread_delete / tx_thread_entry_exit_notify already enforce ownership and are not affected.

This is a genuine but moderate-priority issue, not a top-of-queue emergency. The vendor-supplied CVSS 4.0 base score is 6.9 (Medium) with vector AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:H, meaning local vector, low complexity, and already-held low privileges (a loaded module), with the main impact being high availability loss (permanent thread stop) and low integrity impact (scheduling manipulation); confidentiality is none beyond readable thread metadata. No EPSS score was provided, the CVE is NOT on CISA KEV, and no verified public exploit code was supplied - the only demonstration is the vendor's own proof on QEMU's MPS2 AN385 Cortex-M3 model, which is a controlled research demonstration rather than released weaponised code. The vuln.today decision label is 'this_month', consistent with a real-but-contained issue. SSVC-style reading: exploitation is not observed/active, automatability is low because the attacker must first get a malicious or compromised memory-protected module loaded, and technical impact is partial (DoS and scheduling tampering, no code execution or memory disclosure gained). The signals are mutually consistent - there is no high-CVSS/low-real-risk contradiction and no conflicting data - but note the local vector plus the PR:L precondition (attacker must already run inside a loaded module) sharply limits real-world exploitability to systems that both use the Module Manager and load memory-protected modules.

An attacker who manages to get a malicious or compromised user-mode, memory-protected module loaded enumerates other threads using documented services (txm_module_object_pointer_get_extended by name, and tx_thread_info_get to walk the kernel's created-thread list), then calls the thread-control dispatchers against threads it does not own to suspend, terminate, reset, re-prioritise or abort the waits of application and other-module threads. Lowering the system timer thread's priority stalls every timeout and application timer, denying service without the module gaining any code execution or memory access. No public exploit code was released; the vendor demonstrated the behaviour on QEMU's MPS2 AN385 Cortex-M3 module port.