Eclipse ThreadX CVE-2026-94192

Exploitation requires that the target firmware is built with ThreadX Module support (the Module Manager and loadable modules enabled), and that the attacker can execute code within a module that reaches txm_module_object_deallocate with the address of a still-live kernel object control block (thread, timer, or other object on a created list). This is NOT remotely exploitable and NOT exploitable against a build that does not use loadable modules - the Local vector (AV:L) and PR:L reflect that the attacker must already run as, or control, a module within the RTOS. The limiting factors are: module support must be compiled in and used, the attacker needs module-level execution, and no network-facing default-config path exists.

The input CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) scores 8.5 and is internally consistent with the description: this is a local, low-complexity use-after-free (CWE-416) requiring low privilege - specifically the ability to execute code inside a loaded ThreadX module that can invoke txm_module_object_deallocate. All three impacts (confidentiality, integrity, availability) are High because a dangling kernel control block that remains schedulable or on the timer list, once its bytes are reused by the byte pool, enables memory disclosure, kernel-structure corruption, and crash/hang. No EPSS score was provided and the vulnerability is NOT in CISA KEV; no public exploit (POC) was supplied in the input, so this is a severity-driven priority rather than an evidence-of-exploitation priority. Importantly, the Local attack vector and PR:L mean this is not remotely exploitable against a default appliance perimeter - an attacker must already be able to run or load a malicious/buggy module, which materially lowers real-world risk versus the raw 8.5 would suggest. No signals conflict; the main gap is the absence of EPSS and any exploitation telemetry.

An attacker (or a buggy third-party module) running as a loaded ThreadX module calls txm_module_object_deallocate on the address of a kernel object control block that is still in use - e.g. an active thread or timer. The byte pool then reissues those same bytes to a later allocation while the kernel still treats the stale block as live and schedulable, producing a use-after-free the attacker shapes into kernel memory disclosure or code/control-flow corruption. No public POC was provided in the input data.