🔥 CyberForge CVE of the Day #065 🚨 CVE-2026-102710 — Eclipse ThreadX trace callback privilege escalation A protected module supplies a callback that the kernel later invokes with kernel privilege. Memory protection can remain enabled while that call crosses the boundary it should preserve. Eclipse's CNA describes this flaw in ThreadX builds with event tracing enabled, where an attacker already controls a loaded user-mode, memory-protected module. An invalid callback can fault the kernel; the record also reports module-owned code executing with kernel privilege. The CVSS v4.0 score is 9.3 Critical. No v3.1 score was supplied in the reviewed CNA or NVD records. ⚠️ Check the resident build and loaded modules. No fixed upstream release was verified. 🎯 The quick hit: Identify affected ThreadX firmware, confirm event tracing and module configuration, and establish who can introduce or control loaded modules. Seek an OEM repair. Engineering can assess removing unneeded tracing or excluding the callback service, with product validation and protection settings preserved. 🔑 Key details: ⭐ Severity: Critical 📊 CVSS v4.0: 9.3 — Eclipse CNA 🧮 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` 🧠 Weakness: CWE-269 — Improper Privilege Management; CWE-822 — Untrusted Pointer Dereference 🎯 Target: Eclipse ThreadX through v6.5.1.202602a_rel 🧩 Boundary: Protected module → privileged kernel callback 🌐 Attack vector: Local ⚙️ Attack complexity: Low 🔓 Privileges required: Low; control of a loaded module 👆 User interaction: None ⚔️ Reported impact: Kernel-context execution or kernel DoS 💥 CVSS impact: High confidentiality, integrity and availability impact for vulnerable and subsequent systems 👤 Execution context: CNA reports kernel privilege, with a runtime register capture 🛡️ Fix: No fixed release or CVE-specific patch verified 🚨 Active exploitation: Not confirmed in reviewed sources 🧪 Reproduction: Runtime demonstration described by the CNA; not reproduced by CyberForge 📋 KEV: No match in returned 2026.09.29 catalogue, checked 30 September 📉 EPSS: FIRST returned no data row 📜 Project advisory: GHSA-xr9m-8j99-rw4m, unavailable at review 🏷️ Reporter credited by CNA: SounLabs 🧬 What actually went wrong? A trace callback responds when the trace buffer fills and wraps. A module's lower privilege should be preserved through work scheduled to happen later. The CNA describes a module-supplied pointer invoked directly from privileged code without validation or a module-safe transition. 1️⃣ Registration crosses the boundary A loaded module reaches the notification service through kernel dispatch. The inspected helper passes the supplied pointer onward. 2️⃣ The kernel retains the callback With event tracing compiled in, the notification API stores a global function pointer. 3️⃣ A later wrap invokes it The trace insertion code calls the retained callback when the buffer wraps. Eclipse reports a bad target faulting the kernel and a module-code target running with kernel privilege. The inspected source supports this path. This was static review, not a runtime test; no payload or reproduction harness is included. The prerequisites belong in the headline. The documented case combines a loaded module with `TXM_MODULE_USER_MODE` and `TXM_MODULE_MEMORY_PROTECTION`, a resident build with `TX_ENABLE_EVENT_TRACE`, and access to the relevant dispatch service. The initial route into the module is not established. Local attack vector does not imply physical possession, and no affected network endpoint is specified. Buffer wrap is normal trace behaviour; the weakness concerns callback trust, not a demonstrated buffer-overflow write. ⚔️ The practical attack chain: 1️⃣ Attacker-controlled code is already running in a loaded protected module. 2️⃣ The affected tracing-enabled build exposes callback registration through dispatch. 3️⃣ The module supplies the callback that the kernel retains. 4️⃣ Trace activity eventually reaches the buffer-wrap condition. 5️⃣ Privileged code invokes that callback. 6️⃣ The result can be a kernel fault or the reported kernel-context execution. The mechanism and runtime outcome are CNA-reported; the public source supports the registration and invocation path. No initial-access exploit or subsequent campaign is established. 👤 Execution context — what the attacker actually gets. The CNA reports `CONTROL.nPRIV = 0` captured inside module-owned code, describing kernel privilege. CyberForge did not retrieve the original test artefacts or repeat that measurement. Scope the RTOS kernel's access to memory, peripherals, configuration and secrets, accounting for additional isolation. No TrustZone secure-world escape, persistence, credential theft or movement to other devices is established. Those outcomes require separate evidence. 📦 Affected products and versions: 🔴 Eclipse ThreadX through `v6.5.1.202602a_rel`, with the stated module and trace conditions. The latest release returned by the project API is that same affected tag. Its notes describe build and compilation repairs and say no new vulnerabilities were addressed. The `a` suffix is not evidence of a fix for this September disclosure. Preserve the complete upstream tag and verify OEM ancestry or backports. Do not invent a safe version. OSV maps the last affected tag to a commit but supplies no fixed event. Join the SBOM with the actual resident build and module configuration. A dependency match alone does not establish all prerequisites, and missing package alerts cannot clear embedded firmware. 🕰️ Timeline / exploitation window. 8 June 2026: affected upper tag published. 29 September, 17:37 UTC: CVE publication. 30 September: this review. No earliest attack date is established. Set the hunt window from firmware/module history and retention, not disclosure alone. 👁️ Defender hunting guide: 1️⃣ Confirm what is running Record the product firmware, ThreadX revision, OEM backports and image identifier. Have engineering verify module support, module attributes and effective tracing definitions in the resident kernel and linked libraries. Source defaults or one application header may differ from a shipped library. Retain the build-to-image evidence. 2️⃣ Review module provenance Identify approved modules, admission paths, signing or integrity controls where implemented, and recent module changes. Investigate unapproved loads or mismatches with trusted deployment artefacts. Signatures do not guarantee freedom from compromise. Admission restrictions do not remove code already loaded. 3️⃣ Correlate registration with later faults Where existing telemetry permits, connect unexpected callback registration or handler identity with subsequent trace-wrap activity, kernel faults or resets. Keep the module identity, build, time and relevant fault context together. The callback is global; a different task may be active at the later fault. Investigate earlier registration and consider legitimate callbacks or ordinary firmware defects. 4️⃣ Preserve evidence without creating exposure Preserve retained traces, faults, resets, module logs and approved exports. Record evidence lost on reboot and collection gaps. Do not enable affected tracing or force callback execution on production for investigation. Use retained evidence and authorised lab instrumentation. 5️⃣ Check integrity and scope consequences Compare firmware, modules and security-relevant configuration with the approved baseline. Escalate unexplained privilege behaviour, module changes or integrity failures. A crash alone does not prove exploitation. Scope resources and credentials if kernel compromise is supported. No campaign indicators were verified here. 🩹 Emergency remediation order: 1️⃣ Establish the affected configuration Confirm the resident code, event tracing, loaded module attributes and reachable callback service. Prioritise products that admit less-trusted modules and rely on the privilege boundary for isolation. 2️⃣ Preserve evidence and control module changes Retain history and restrict unauthorised module changes. Coordinate suspected-compromise containment with the product owner and assess operational effects. 3️⃣ Obtain an OEM or maintainer response Request a CVE-specific fix or supported mitigation mapped to the exact product firmware. The linked project advisory was unavailable, and no fixed upstream release was verified during this review. 4️⃣ Validate an engineering mitigation if necessary Assess removing unneeded tracing or excluding the module callback service. Confirm compatibility with legitimate modules, diagnostics and timing before deployment. 5️⃣ Verify the actual image Retain source, build, binary and regression evidence. Confirm the running device received the intended image. 6️⃣ Recover trust where compromise warrants it Recover trusted firmware and modules; rotate exposed secrets where justified. A reboot does not remove the vulnerable code or necessarily remove a malicious module. 🧱 Temporary exposure reduction. The following are CyberForge engineering interpretations of the source, not published maintainer workarounds or tested changes: ✅ Remove unnecessary event tracing from the resident build. The code uses `#ifdef TX_ENABLE_EVENT_TRACE`. Defining that macro as `0` still leaves it defined. Verify effective preprocessing and prebuilt libraries; merely hiding trace output does not remove the path. ✅ Assess excluding this callback service. The resident module dispatch is guarded by `TXM_TRACE_BUFFER_FULL_NOTIFY_CALL_NOT_USED`. A correctly rebuilt manager with this service excluded may remove this route, subject to integration review. A definition only in a client module does not prove the kernel path was excluded. ✅ Tighten module admission and integrity controls. Review who can load, replace or modify modules and what is already running. Keep user-mode and memory protection enabled. Granting modules kernel privilege or disabling their protection would defeat the boundary being defended. Feature exclusion also affects diagnostics, so record that trade-off and the restoration plan. 🚑 When vulnerability management becomes incident response. Escalate evidence of unauthorised modules, unexpected privileged execution, unexplained callback targets or firmware/configuration integrity changes. Correlate faults and resets with these findings; neither a version match nor a watchdog reset proves an attack. Preserve what the product can safely provide and scope the kernel's actual reach. A generic desktop endpoint hunt may not exist on this RTOS; detection must reflect available device and fleet telemetry. 📊 CISA KEV and EPSS context. At the 30 September check, CISA's returned 2026.09.29 catalogue contained no exact match. Its 13:51 UTC release predates this CVE's 17:37 UTC publication, so retain the snapshot limitation. FIRST returned no EPSS row. Missing data is not zero probability, and no CISA ADP assessment was present in the retrieved record. Prioritise documented prerequisites and product impact instead of turning absent enrichment into reassurance. 🧾 Evidence separation. Project/CNA-supported: the affected range, local low-privilege attacker model, tracing and module prerequisites, kernel fault and reported privilege measurement. CyberForge source review: four files at the affected tag support forwarding, storage and invocation of the callback, with build guards relevant to mitigation review. CyberForge interpretation: join module provenance and actual build configuration; validate any service/feature exclusion through product engineering. Not established: an accessible full project advisory, verified fixed release, independent runtime test, standalone public exploit or active campaign. 🔥 CyberForge verdict: CVE-2026-102710 makes the privilege boundary behind an ordinary diagnostic feature operationally important. A product's exposure depends on the loaded module and the code that was actually compiled into its resident kernel. The correct order is to confirm that configuration, control module trust, obtain a supported repair or validate mitigation, verify the running image, and investigate evidence of prior compromise. > A protected module stays protected only if its callbacks keep the same privilege boundary. Research cutoff: 30 September 2026, 09:42 BST / 08:42 UTC. Source and document review only; no firmware build, device test or exploit execution was performed. 🔗 Eclipse CNA / CVE record: https://www.cve.org/CVERecord?id=CVE-2026-102710 🔗 NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-102710 🔗 Latest returned release — within the affected range: https://github.com/eclipse-threadx/threadx/releases/tag/v6.5.1.202602a_rel 🔗 Module dispatch source at the affected tag: https://github.com/eclipse-threadx/threadx/blob/v6.5.1.202602a_rel/common_modules/module_manager/inc/txm_module_manager_dispatch.h#L3033 🔗 Trace callback setter: https://github.com/eclipse-threadx/threadx/blob/v6.5.1.202602a_rel/common/src/tx_trace_buffer_full_notify.c#L69 🔗 OSV record: https://api.osv.dev/v1/vulns/CVE-2026-102710 #CyberSecurity #CVE #EclipseThreadX #RTOS #PrivilegeEscalation #EmbeddedSecurity #BlueTeam #CyberForge