Eclipse ThreadX EUVD-2026-115230

Exploitation requires that the system both uses the Module Manager and loads module images through txm_module_manager_in_place_load(), txm_module_manager_memory_load(), txm_module_manager_absolute_load(), txm_module_manager_absolute_load_extended(), or txm_module_manager_file_load(); deployments that do not use the Module Manager are unaffected. The attacker must control a module image the device loads and set its preamble data size, start/stop stack size, or callback stack size close to ULONG maximum so the allocation arithmetic overflows. The CVSS vector shows PR:L, indicating authenticated/privileged ability to supply that module (authentication required per PR:L), with no user interaction (UI:N) and a local vector (AV:L). Impact is limited to denial of further Module Manager operations until system reset; confidentiality and integrity are unaffected.

This is a genuine but bounded availability issue, not a top-tier emergency. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) describes a local, low-complexity attack requiring some privilege (PR:L), with impact confined entirely to availability of the vulnerable system (VC:N/VI:N/VA:H) and no scope change - consistent with a CWE-667/CWE-833 locking/deadlock defect rather than memory corruption. The vendor advisory confirms 'nothing is read or written out of bounds,' so despite the 'Buffer Overflow' tag this is not a code-execution or data-disclosure bug. No EPSS score was supplied, the CVE is not in CISA KEV, and no working exploit code is referenced (only the GHSA advisory and an Eclipse GitLab work item), so there is no signal of active or widespread exploitation. The vuln.today decision label is 'this_month,' aligning with the Medium (6.8) severity and the local, privilege-requiring vector - a real priority to patch on a normal cadence rather than an act-now/emergency item. The limiting factor is exposure: only deployments that use the Module Manager and load externally-supplied module images are at risk, and the attacker must already control a module the device loads.

An attacker who can supply or tamper with a loadable module image sets the preamble's data size or stack size near the maximum of a ULONG. When the device loads that image, the Module Manager detects the arithmetic overflow and returns an error without releasing its protection mutex, so every subsequent load/start/stop/unload from any other thread blocks forever until the system is reset. No public working exploit code is identified at time of analysis; local, low-complexity access to module input is required.