Eclipse ThreadX CVE-2026-94023

Requires a ThreadX deployment using the Module Manager with loadable modules, and an attacker who already has code execution inside one such module (PR:L, AV:L - local only). The attacker must obtain a pointer to a kernel object it does not own (a shared queue, semaphore, or mutex created by the application or another module), typically via txm_module_object_pointer_get_extended name lookup, then route that pointer to the object delete service through the privileged dispatcher. Limiting factors: exploitation is impossible without the module feature in use and without multiple/mixed-trust modules; it provides no confidentiality access (VC:N), requires no user interaction, and cannot be triggered remotely - firmware built as a single trusted monolithic image is not exposed.

The vendor-supplied CVSS 4.0 vector (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H) scores 6.9 (Medium) and is internally consistent with the description: this is a local, low-complexity authorization flaw exploitable only by an already-loaded ThreadX module (PR:L), not a remote network issue. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so there is no evidence of active or opportunistic exploitation - the practical risk is bounded to systems that actually deploy loadable ThreadX modules in a mixed-trust configuration. The real threat is a privilege/isolation boundary violation: a module can name any kernel object it holds a pointer to (including objects owned by the application or other modules) and have the privileged Module Manager dispatcher delete it, yielding integrity and availability impact (VC:N confirms no confidentiality loss). Note a signal conflict: the input Tags ('Buffer Overflow', 'Information Disclosure') and CWE-125 (out-of-bounds read) do NOT match the described logic/authorization defect or the VC:N/VI:H/VA:H impact profile - this is arbitrary object destruction, not a memory-read bug, so the categorization appears mislabeled and should be treated with caution. This is a legitimate-but-moderate priority: meaningful for multi-module/multi-tenant embedded deployments, low urgency for single-trusted-image firmware.

In a device running multiple ThreadX loadable modules, a compromised or malicious lower-privileged module calls txm_module_object_pointer_get_extended to resolve a pointer to a shared queue, semaphore, or mutex it does not own, then invokes the kernel object delete service through the Module Manager's dispatch layer. Because the dispatcher only checks that the object lies outside the caller's own code/data (the policy for using shared objects), the privileged delete succeeds, destroying another module's or the application's kernel object and causing crashes, deadlocks, or denial of service. No public exploit identified at time of analysis; local module-level code execution (PR:L) is required.