High severity · published Oct 20, 2026
CVE-2026-95107
Module object allocation size overflow corrupts the manager object pool
7.0
CVSS
0.2%
EPSS
No
On KEV
Description
A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block.
Exploitation
Is it being used?
Exploit prediction (EPSS)0.2% · higher than 4% 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-95107
CVE.org
https://www.cve.org/CVERecord?id=CVE-2026-95107
github.com
https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-63qc-jcr6-qw6r
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
6.9
CVE-2026-94024
Module Manager object lookup validates one byte of a module's search name
6.9
CVE-2026-94023
Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion
6.8
CVE-2026-95108
Deleting a user-mode module thread leaks its privileged kernel stack
