lee1981 (@lee1981b) on X

What it is

CVE-2026-102710 — a privilege-escalation flaw in Eclipse ThreadX RTOS (through v6.5.1.202602a_rel), CVSS v4.0 9.3 Critical, vector CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Reported by SounLabs via Eclipse's CNA; project advisory GHSA-xr9m-8j99-rw4m was unavailable at review. The summary has the mechanism; what follows is the config- and macro-level detail an engineer needs to actually scope and mitigate it.

Preconditions (all must hold)

The vulnerable path only exists when a specific combination is compiled and loaded:

• Resident kernel built with TX_ENABLE_EVENT_TRACE.
• A loaded module with both TXM_MODULE_USER_MODE and TXM_MODULE_MEMORY_PROTECTION.
• Attacker already running code inside that protected module, with access to the callback-registration dispatch service.

Initial access into the module is not established by the report. Local attack vector does not mean physical access, and no network endpoint is specified.

What to do

CyberForge's exposure-reduction steps (their interpretation, not maintainer-published workarounds), with the traps that make naive mitigation fail:

• Remove event tracing from the resident build. The code guards on #ifdef TX_ENABLE_EVENT_TRACE. Defining the macro as 0 still leaves it defined — the path stays. Verify effective preprocessing and any prebuilt libraries; suppressing trace output does not remove the callback path.
• Exclude the callback service. Module dispatch is guarded by TXM_TRACE_BUFFER_FULL_NOTIFY_CALL_NOT_USED. A correctly rebuilt module manager with this service excluded may remove the route — but a definition only in a client module does not prove the kernel path was excluded.
• Keep user-mode and memory protection enabled. Granting modules kernel privilege or disabling protection defeats the boundary being defended.
• Tighten module admission/integrity. Control who can load or replace modules; audit what is already loaded (signatures don't prove a loaded module is clean).

Version note: the latest release returned by the project API is the same affected tag v6.5.1.202602a_rel. Its notes cover build/compilation fixes and state no new vulnerabilities were addressed — the a suffix is not a fix for this disclosure. Do not invent a safe version; verify OEM ancestry/backports and join the SBOM to the actual resident build.

Detection

Where telemetry allows, correlate unexpected callback registration with subsequent trace-wrap activity, kernel faults or resets — keeping module identity, build, and time together. Note the callback is global, so a different task may be active at the later fault. Do not enable the affected tracing or force callback execution on production to investigate; use retained evidence and authorised lab instrumentation only.

Caveats

Static source review only — four files support the register/store/invoke path; no runtime test, exploit, or reproduction harness. Kernel-privilege claim (CONTROL.nPRIV = 0) is CNA-reported, not re-measured. No KEV match (30 Sept check) and no EPSS row — absence of enrichment is not reassurance. No fixed release verified. Timeline: affected tag published 8 June 2026; CVE published 29 Sept 2026 17:37 UTC.