Eclipse ThreadX CVE-2026-95107

Exploitation requires that the deployment uses the ThreadX Module Manager (txm) feature and that the attacker can execute code as a loaded module able to call txm_module_object_allocate with an attacker-influenced object_size close to ULONG_MAX. The triggering condition is the unchecked addition of the Module Manager's fixed 16-byte private header to that size, which wraps the total. Limiting factors: the attack is LOCAL (AV:L) and requires low privileges (PR:L) - the attacker must already be running within a module context - and only affects builds that compile in and use ThreadX modules; firmware that does not use the module subsystem is not exposed. No user interaction is required (UI:N).

This is a moderate-risk, locally-exploitable memory-corruption flaw rather than a remote-critical issue. The vendor-supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H, score 7.0) is internally consistent with the description: exploitation is LOCAL (AV:L), requires some privilege (PR:L - a module already running under the Module Manager), needs no user interaction, and yields high integrity and availability impact with only limited confidentiality exposure - matching a heap/byte-pool header overwrite that corrupts a neighbouring block (CWE-190 integer overflow). No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the only reference is the Eclipse ThreadX GHSA security advisory. The 'Information Disclosure' tag is only partially supported - the write-past-end primitive is primarily an integrity/availability (memory corruption) issue, with confidentiality rated only Low (VC:L), so the tag overstates the disclosure angle. Net: a genuine but not emergency priority - real because it is an attacker-influenceable allocation overflow in a very widely deployed RTOS, but tempered by the local attack vector and the need to already be executing as a ThreadX module.

An attacker able to load or run a low-privilege ThreadX module requests an object allocation with an object_size near the top of a ULONG; the Module Manager adds its 16-byte private header without an overflow check, the sum wraps to a tiny value, and the byte pool returns a block far smaller than the header. The manager then writes the 16-byte header past the end of the undersized block into the adjacent byte-pool block, corrupting neighbouring memory. No public exploit code is identified at time of analysis.