# CVE-2026-94192: Eclipse ThreadX module object deallocation use-after-free

Source: https://junglewise.ai/threats/cve-2026-94192-a-threadx-module-allocates-the-control-blocks-of-its-kernel  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-10-20. Updated: 2026-10-20  
License: CC BY 4.0 with a link back

CVE-2026-94192 · Severity: info · Published 2026-10-20

Eclipse ThreadX is a real-time operating system kernel used in embedded systems. A flaw in the module manager allows a low-privilege module to deallocate kernel objects while they are still in use by the system, leading to memory corruption and potential code execution. An attacker can trigger use-after-free conditions that corrupt critical kernel data structures and hijack program control flow.

Technologies: [Eclipse ThreadX](https://junglewise.ai/threats/technologies/threadx). Vendors: [Eclipse](https://junglewise.ai/threats/vendors/eclipse).

## Quick answers

**Is CVE-2026-94192 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-94192 being exploited in the wild.

**How severe is CVE-2026-94192?** Informational severity, published 20 October 2026.

**Which products and versions are affected?** Eclipse ThreadX 6.0.1 through 6.5.1.202602a.

**Is there a fix for CVE-2026-94192?** Yes: fixed in 6.5.2.202603. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-94192 attacked?** It is attacked with local access, in an operating system.

**Am I affected by CVE-2026-94192?** Check whether you run Eclipse ThreadX at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## How to fix

- Fixed in 6.5.2.202603

## Technical details

The txm_module_object_deallocate function releases memory from the Module Manager's object pool without verifying that the kernel object is no longer in use. Deallocation does not remove the object from active kernel lists (created lists, ready lists, timer lists), so the kernel continues to dereference the freed memory. A module can then reallocate the same memory and place attacker-controlled data at the same offsets, enabling arbitrary reads and function pointer dereferences in privileged context.

## Affected products

- Eclipse ThreadX 6.0.1 through 6.5.1.202602a

## Timeline

- 2026-10-02: disclosed
- 2026-10-20: advisory

## References

- [https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-57mf-w87f-rq7m](https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-57mf-w87f-rq7m)

## Related threats

- [Eclipse ThreadX Module Manager privilege escalation via forged callback](https://junglewise.ai/threats/cve-2026-115231-in-eclipse-threadx-versions-6-0-1-through-6-5-2-202603-the)
- [Eclipse ThreadX Modules use-after-free in trace-buffer callback](https://junglewise.ai/threats/cve-2026-113421-in-eclipse-threadx-versions-6-0-1-through-6-5-2-202603-threadx)
- [Eclipse ThreadX Module Manager missing authorization in thread control](https://junglewise.ai/threats/cve-2026-115654-in-eclipse-threadx-versions-6-0-1-through-6-5-2-202603-the)
- [Eclipse ThreadX Cortex-M stack pointer memory access in privileged mode](https://junglewise.ai/threats/cve-2026-115653-in-eclipse-threadx-versions-6-0-1-through-6-5-2-202603-the)
- [Eclipse ThreadX Module Manager mutex deadlock in preamble size validation](https://junglewise.ai/threats/cve-2026-118052-in-eclipse-threadx-versions-6-0-1-through-6-5-2-202603-the)