Eclipse ThreadX CVE-2026-94202

Exploitation requires the ThreadX Module Manager to be in use with memory-protected (MPU-isolated) modules, and the attacker must control a module that calls the block-pool create dispatcher (_txm_module_manager_tx_block_pool_create_dispatch) with an extra-parameter array laid out so indices 1, 2, and 3 fall outside the two ALIGN_TYPE words the manager verified as module-owned. Limiting factors: not remotely reachable (AV:L); requires an already-loaded, low-privilege module context (PR:L), so it presupposes the ability to run untrusted module code; builds that do not use the module manager or do not enable memory protection are not affected; impact is confined to a bounded out-of-bounds read (information disclosure and possible fault), not code execution or memory corruption.

All signals point to a medium-severity, low-urgency issue rather than an emergency. The input CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:L) and score of 4.8 describe a local, low-privilege attack with only low confidentiality and low availability impact and no integrity impact - consistent with a bounded out-of-bounds read (CWE-125) of at most two ALIGN_TYPE words beyond the region the Module Manager actually proved the module owns. There is no CISA KEV entry and no POC referenced in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' No EPSS score and no SSVC decision data were provided, so automatable/exploitation-maturity cannot be scored - this absence should not be read as 'safe,' only as 'unmeasured.' The vector is local and requires PR:L, meaning the attacker must already be running a memory-protected module inside the module manager; this is precisely the threat model ThreadX's MPU isolation is meant to contain, which is why the finding matters despite the modest score. Net: a real but low-priority hardening fix for embedded/RTOS vendors shipping the module manager, not a drop-everything issue. No conflicting signals were detected in the input (description's local/module-supplied-parameter framing agrees with AV:L and PR:L).

A memory-protected module running under the ThreadX Module Manager invokes the block-pool create service and supplies an extra-parameter array positioned so that only the first two ALIGN_TYPE words fall inside the module's verified data region. When the dispatcher reads index 1 (pool start) and index 2 (length) to range-check the request - and later index 3 while building the service argument list - it reads words the manager never proved the module owns, disclosing adjacent memory and validating the pool start against attacker-adjacent data. No public exploit code is referenced in the provided data.