Eclipse ThreadX CVE-2026-115231

Exploitation requires the device to use the ThreadX Module Manager and to load at least one user-mode, memory-protected module that the attacker controls or can influence; no special build option is needed. The concrete trigger: the attacker's module walks the kernel's created-queue list (tx_queue_info_get) to reach another module's callback request queue and sends a message of type TXM_QUEUE_SEND_CALLBACK (or another callback type) naming an attacker-chosen function and argument, which the receiving module's callback thread calls without authenticating the sender. Full privilege escalation additionally requires that the targeted receiving module runs in privileged mode; against a user-mode receiving module the attacker can still invoke functions in that module's context or fault/drain its callback thread. Limiting factors: no network vector (local, on-device only), the attacker must already be able to run a memory-protected module, and kernel-level escalation specifically depends on a privileged module being present alongside the attacker's.

The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, 8.5 High) describes a locally-exploitable, low-complexity flaw that requires the attacker to already hold some privilege on the device - specifically the ability to run a user-mode, memory-protected module (PR:L). It is not network-reachable, so mass remote exploitation is not the threat model; the realistic risk is a malicious or compromised module escaping its isolation. Impact is severe where it applies: full confidentiality, integrity and availability loss via module-to-kernel privilege escalation, defeating the Module Manager's entire isolation guarantee. The vuln.today decision label is 'this_week', indicating elevated but not emergency urgency, consistent with a high-impact bug gated by a meaningful access precondition. This is NOT in CISA KEV and no EPSS score was provided in the input, so there is no signal of active or widespread exploitation; absence of those signals is expected for an on-device RTOS escalation that is hard to exploit at internet scale. The subsequent-system metrics are None (SC:N/SI:N/SA:N) because the flaw and its impact are both confined to the device. Net: a genuine high-priority issue for anyone running the Module Manager with attacker-influenced modules alongside a privileged module, but the local, loaded-module precondition keeps it below drop-everything emergency level.

An attacker who can get a malicious user-mode, memory-protected module loaded on a ThreadX device running the Module Manager enumerates the kernel's queue list to find another module's callback request queue, then posts a forged callback message naming a function of the attacker's choosing. The target module's callback thread invokes that function pointer without verifying it came from the Module Manager, so when the target runs in privileged mode the attacker's code executes with kernel privilege. No public exploit code is referenced, but the reporter (SounLabs) privately reproduced it on Cortex-M3 under QEMU (mps2-an385), observing the function run with CONTROL.nPRIV=0.