Medium severity · published Oct 20, 2026
CVE-2026-94023
Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion
6.9
CVSS
0.1%
EPSS
No
On KEV
Description
A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for *using* an object, and using an object a module does not own is supported and intended — `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex.
Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it.
Exploitation
Is it being used?
Exploit prediction (EPSS)0.1% · higher than 3% of CVEs
Exploited in the wildNo evidence yet
CISA KEVNot listed
Ransomware campaign useNot known
Affected products
Which versions
ET
Eclipse ThreadX · Eclipse Foundation
6.0.1 through 6.5.1.202602a · source: vendor
References
NVD
https://nvd.nist.gov/vuln/detail/CVE-2026-94023
CVE.org
https://www.cve.org/CVERecord?id=CVE-2026-94023
github.com
https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-36vf-7cx6-9f9j
More from Eclipse ThreadX
8.5
CVE-2026-95109
Cortex-A7 module data validation checks only the first address of a caller-supplied range
8.5
CVE-2026-94192
Module object deallocation can free a live ThreadX kernel object
7.0
CVE-2026-95107
Module object allocation size overflow corrupts the manager object pool
6.9
CVE-2026-94024
Module Manager object lookup validates one byte of a module's search name
6.8
CVE-2026-95108
Deleting a user-mode module thread leaks its privileged kernel stack
