---
id: "CVE-2026-115231"
kind: "vulnerability"
aliases: ["CVE-2026-115231"]
title: "Eclipse ThreadX: user-mode module can run code with privileged access"
severity: "high"
cvss: 8.5
epss: null
exploited: false
status: "open"
category: "runtime"
products: [{"name": "threadx", "fixed": ["6.5.2.202603b"], "affected": ">= 6.0.1, <= 6.5.2.202603", "ecosystem": "vendor"}]
ecosystems: []
tags: ["embedded", "module-manager", "rtos", "runtime", "threadx"]
not_affected_if: ["module-manager-unused", "no-user-mode-modules"]
published_at: "2026-11-03T09:17:10+00:00"
first_seen_at: "2026-11-03T09:19:50+00:00"
updated_at: "2026-11-03T09:21:11+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115231", "first_seen_at": "2026-11-03T09:19:50+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-03T09:21:11+00:00"}]
---

# Eclipse ThreadX: user-mode module can run code with privileged access

In Eclipse ThreadX 6.0.1 through 6.5.2.202603, a user-mode module can post a forged callback request to another module's queue. The receiving module calls the attacker-supplied function pointer without verifying the sender, so the attacker's code runs with that module's privilege.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:threadx affected >= 6.0.1, <= 6.5.2.202603 fixed 6.5.2.202603b

## How to check

- Check your ThreadX version: 6.0.1 through 6.5.2.202603 is affected; 6.5.2.202603b is fixed.
- Check whether your build uses the ThreadX Module Manager with memory-protected user-mode modules (ThreadX Modules). If it does not, it is not reachable.
- Check whether any module that owns a callback request queue runs in privileged mode; that is where forged callbacks gain privilege.

## Fix

Upgrade to Eclipse ThreadX 6.5.2.202603b (hotfix release). After the fix a memory-protected module can no longer send to, flush or receive from another module's callback request queue (returns TXM_MODULE_INVALID); designs relying on that need a shared synchronisation object instead.

## Timeline

- 2026-11-03T09:19:50+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-115231
- 2026-11-03T09:21:11+00:00 analyst — Read vendor release notes for v6.5.2.202603b (eclipse-threadx/threadx releases): fixed in 6.5.2.202603b, affects 6.0.1 through 6.5.2.202603, needs local code execution, not network reachable, no exploitation or PoC seen. GHSA page itself returned empty; advisory list confirms title and High rating. Did not check X.

## Documents

- [advisory] Vendor advisory: github.com https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-q2rc-f35r-2hw6
- [fix] ThreadX v6.5.2.202603b release notes https://github.com/eclipse-threadx/threadx/releases

## From the sources

In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager lets a user-mode, memory-protected module post a forged callback request to another module's callback request queue. The receiving module's callback thread calls the function pointer in the request without checking that the Module Manager sent it, so the attacker's code runs with the receiving module's privilege; when that module runs in privileged mode, a user-mode module gains privileged execution.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_