Eclipse ThreadX CVE-2026-102711

Exploitation requires that the device actually use the ThreadX loadable-module subsystem and load an attacker-controlled module object through _txm_module_manager_memory_load or _txm_module_manager_in_place_load. These APIs take only a base pointer and no image length, so every size/offset field in TXM_MODULE_PREAMBLE (notably code_size, used as the source-image length in the code-copy loop) is fully trusted from the attacker-supplied image, and the preamble checksum is never verified. Limiting factors: the attack vector is local (the malicious module must already be present in the device's memory/load path), it requires operator/user action to trigger the load (UI:A), attack complexity is high, and the impact is bounded to an OOB read plus a CFI/defense-in-depth gap - no controlled OOB write is possible because the copy destination is overflow-guarded. Systems that never load third-party or externally supplied modules are not exposed.

This is a genuinely low-to-moderate real-world risk despite the memory-corruption CWE class. The vendor CVSS 4.0 vector (AV:L/AC:H/AT:N/PR:N/UI:A, VC:H/VI:N/VA:L → 5.7) is internally consistent with the description: exploitation is local (the malicious module object must already be delivered to and loaded by the device), attack complexity is high, and success is gated on user/operator action (UI:A) to invoke _txm_module_manager_memory_load/_txm_module_manager_in_place_load. There is no EPSS score, no CISA KEV listing, and no public exploit code, so exploitation status is 'no public exploit identified at time of analysis' - this is a self-reported Eclipse advisory (GHSA-f53h-37j4-mqxx), not an in-the-wild finding. The technical impact is bounded to a heap OOB read (information disclosure, VC:H) plus a defense-in-depth/CFI gap (unverified checksum and !=0-only pointer checks); the advisory is explicit that NO controlled OOB write was found because the copy destination is overflow-guarded, so this is not a straightforward RCE primitive. The primary signal tension is prevalence versus trigger: ThreadX is extremely widely deployed, but the loadable-module loader is an optional subsystem and the trust boundary (loading an attacker-controlled module image) is unusual, so this is a high-CVSS-context product with a narrow, non-default exploitation path rather than a fleet-wide emergency.

An attacker supplies a maliciously crafted ThreadX loadable-module object (e.g., via a firmware/module update channel or a supply-chain path) whose TXM_MODULE_PREAMBLE declares an oversized code_size. When the device operator loads the module through _txm_module_manager_memory_load/_txm_module_manager_in_place_load - APIs that accept only a base pointer with no length - the code-copy loop reads out of bounds past the source image, disclosing adjacent heap memory, and the unverified entry/start pointers weaken control-flow integrity. No public proof-of-concept exists; exploitation is local and requires operator action to load the module.