Eclipse ThreadX EUVD-2026-89112

Requires a deployment that uses the ThreadX Module feature with MPU-based memory protection enabled (the isolated 'memory-protected module' model), and the attacker must already be able to run code as such an unprivileged module - e.g. by supplying or compromising a loadable module. This is a local vector (AV:L) with attacker-controlled code already executing (PR:L), no user interaction, and no network exposure. It does not affect ThreadX builds that do not use isolated modules/MPU. The gating factor is therefore the presence of the module-isolation deployment mode plus the ability to introduce or subvert a module, not raw network reachability.

The vendor CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H = 8.5) is internally consistent with the description: this is a local, low-complexity privilege-escalation flaw requiring that attacker-controlled code already run as a loaded ThreadX module. The 'unprivileged' module is not a remote actor - PR:L reflects that the attacker must already be executing code inside a memory-protected module, which is a meaningful prerequisite. No EPSS score, no CISA KEV listing, and no public exploit code were provided; the advisory describes a 'reported chain' (a credible internal proof, not a released weaponized exploit), so this is not confirmed in-the-wild exploitation. The realistic risk is HIGH severity but NARROW reach: the impact (full MPU/isolation bypass to privileged kernel memory read/write) is critical, but it only matters where the ThreadX Module Manager with MPU isolation is actually deployed AND an attacker can supply or already controls a module. Note a labeling tension worth verifying: CWE-125 (out-of-bounds read) understates the flaw - the described primitive is a type-confusion of a forged control-block ID leading to an arbitrary privileged write (memset over an attacker-chosen range), i.e. closer to CWE-843/CWE-787 privilege escalation than a pure OOB read.

An attacker who can load or already runs an unprivileged, memory-protected ThreadX module crafts a fake object control block inside one of its own privileged allocations, forging the control-block ID so the _txe_ layer accepts it as a valid kernel object. Passing the interior address to a privileged service (the reported chain reaches a privileged memset) yields arbitrary kernel-mode memory read/write, which is then used to clear the MPU enable bit and dissolve the module's isolation boundary. No public exploit is available, but the vendor advisory documents a working chain.