Eclipse ThreadX CVE-2026-95111

Requires the ThreadX memory-protected module feature (Module Manager with MPU isolation) to be in use, and the attacker must already control a loaded module that is low-privileged yet authorized to perform a front-send on a target queue; a second module (or the same one) must be able to receive from that queue to read the leaked words back. Exploitation is strictly local (AV:L) and authenticated at the module level (PR:L) - it cannot be reached remotely or without executing code as a module. The leak is bounded to 3×message_size bytes immediately past the module's readable region, limiting it to an adjacent-memory information-disclosure primitive rather than arbitrary read. Deployments that do not use ThreadX Modules, or that use the module manager without relying on it as a security boundary, are not meaningfully exposed.

This is a genuine but low-severity, narrowly-scoped defect, consistent with its 4.8 CVSS 4.0 score. The vector (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:L) tells a coherent story: a local attacker who already controls a low-privileged, memory-protected ThreadX module can trigger an out-of-bounds read (CWE-125), leaking a bounded amount of adjacent memory back into the module via the queue it reads from. The description and the CVSS vector agree - this requires attacker code already executing as a loaded module (PR:L, AV:L), not remote or unauthenticated access, so it is a privilege/isolation-boundary weakness rather than an initial-access vulnerability. No EPSS score, KEV listing, or public exploit was provided; the only intelligence source is the Eclipse ThreadX GHSA advisory (GHSA-rrg6-24r9-wqpm). The disclosed amount is deterministic and small (3 × message_size bytes past the readable region, since a ULONG word count was passed where a byte count was expected), and the leak is an information-disclosure primitive confined within the privileged copy path - not code execution. Net: a legitimate memory-safety fix that matters for high-assurance MPU-isolated deployments, but not a broad-fleet emergency. Prioritize patching where ThreadX Modules with memory protection are used to enforce a security boundary; deprioritize elsewhere.

A malicious or compromised low-privileged ThreadX module issues a front-send queue request crafted so its source buffer ends exactly at the edge of the module's readable region. The Module Manager's front-send dispatcher passes the raw ULONG word count instead of the byte count, so the privileged copy reads 3×message_size bytes beyond the allowed boundary and writes them into the queue's message area, where a module receiving from that queue reads back the leaked adjacent privileged/kernel memory. No public exploit code was identified at time of analysis.