CVE-2026-94023
Published:October 20, 2026
Updated:October 22, 2026
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.
Affected Packages
https://github.com/eclipse-threadx/threadx.git (GITHUB):
Affected version(s) >=v6.0.1_rel <v6.5.2.202603_relFix Suggestion:
Update to version v6.5.2.202603_relAdditional Notes
The description of this vulnerability differs from MITRE.
Related Resources (1)
Do you need more information?
Contact UsCVSS v4
Base Score:
6.9
Attack Vector
LOCAL
Attack Complexity
LOW
Attack Requirements
NONE
Privileges Required
LOW
User Interaction
NONE
Vulnerable System Confidentiality
NONE
Vulnerable System Integrity
HIGH
Vulnerable System Availability
HIGH
Subsequent System Confidentiality
NONE
Subsequent System Integrity
NONE
Subsequent System Availability
NONE
CVSS v3
Base Score:
7.1
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
HIGH
Availability
HIGH
EPSS
Base Score:
0.13