Eclipse ThreadX CVE-2026-95109

Requires the target to use the Eclipse ThreadX Module Manager with memory-protected modules on the Cortex-A7 MMU port specifically - the defective single-address range-check macro is unique to that port's implementation. The attacker must already be able to execute code within a protected module (PR:L) and call a dispatched service that consumes a caller-supplied buffer or extra-parameter array; the exploit works precisely because the module's own first byte is legitimately user-readable while the rest of the declared range is not. Exploitation is limited to local access on affected Cortex-A7/MMU deployments; systems not using module memory protection, or using other architecture ports, are not affected by this specific primitive, and no remote or unauthenticated path exists.

This is a genuine, high-severity defect in a security primitive rather than a cosmetic high-CVSS finding, but its real-world urgency is tempered by a local, authenticated attack surface. The vendor-style CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) scores 8.5 and confirms the flaw is reachable only with local presence and some existing privilege - specifically the ability to run code inside a memory-protected ThreadX module - not remotely or unauthenticated. The technical impact is severe and automatable once that foothold exists: the broken range check (CWE-125, out-of-bounds read, but the description also establishes out-of-bounds write via 'read or wrote the whole range', matching VI:H/VA:H) is the single primitive every protected-module dispatcher relies on, so it effectively dismantles the MMU memory-protection boundary the whole module model depends on. No EPSS score, SSVC decision, KEV listing, or POC was supplied in the input; there is no public exploit identified at time of analysis and no evidence of active exploitation. The limiting factor is the prerequisite of already executing within a protected module on the specific Cortex-A7 MMU port, so this is a privilege-boundary-escape / sandbox-escape risk for systems that both use ThreadX module manager with memory protection AND run on Cortex-A7 with the MMU port - not a mass-exploitable remote bug. Note the CVSS 4.0 subsequent-system metrics are all N (SC:N/SI:N/SA:N), which undersells that the impact crosses a privilege boundary into privileged dispatch code; treat this as a module-to-kernel escalation despite the N subsequent-impact marking.

An attacker who can load or run a memory-protected ThreadX application module on a Cortex-A7/MMU target invokes a privileged service through the module dispatcher, passing a buffer or extra-parameter array whose first byte lies in its own readable memory but whose length extends far beyond its sandbox. The dispatcher's range-check macro validates only that first byte against the MMU and then lets privileged code read from or write to the entire out-of-bounds range, letting the module read kernel/other-module memory or corrupt it. No public POC is referenced; exploitation is local and requires low privilege (the ability to execute within a protected module).