CVE-2026-102711 Memory corruption in `eclipse-threadx/threadx` (module manager / loadable-module loader)
Attacker-controlled module loading in ThreadX RTOS allows heap out-of-bounds reads and bypasses integrity checks, potentially leading to code execution or denial of service.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Local or same network only
- Victim action needed
- A user has to click or open something
- Fix
- None listed
What is CVE-2026-102711?
CVE-2026-102711 is a medium-severity memory corruption vulnerability in `eclipse-threadx/threadx` (module manager / loadable-module loader), published on 29 Sep 2026. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.
Official description
Two issues in the ThreadX loadable-module loader, reached when a device loads an attacker-controlled module object via `_txm_module_manager_memory_load` / `_txm_module_manager_in_place_load` — APIs that take ONLY a base pointer, no image length, so every size/offset field in `TXM_MODULE_PREAMBLE` is fully attacker-trusted: (1) a heap OOB **read** (`code_size` trusted as the source-image length in the code-copy loop), and (2) a control-flow-integrity / defense-in-depth gap (module entry/start/callback/stop pointers computed as `code_start + preamble_offset` with only a `!= 0` check, and the preamble `checksum` never verified). No controlled OOB write was found (honest — the copy destination is overflow-guarded).
Which versions are affected by CVE-2026-102711?
How do I fix CVE-2026-102711?
No fix has been published for CVE-2026-102711 yet. Limit exposure of the affected software until one is available.
Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.
Is CVE-2026-102711 being exploited?
There is no known exploitation of CVE-2026-102711 in the wild and no public exploit code.
Sources
Also known as GHSA-w4rq-vh43-v5q5.