Eclipse ThreadX CVE-2026-115653

Requires a system using the ThreadX Module Manager on a Cortex-M module port (Cortex-M0+, M3, M4, M7, M23 or M33, any supported toolchain) that loads a user-mode, memory-protected module the attacker controls; the attacker's module freely sets its process stack pointer to point just above the start of its own data region or of an application-granted writable shared region. Limiting factors that bound real-world risk: exploitation is local only (no remote trigger), the attacker must already be running code inside a loaded memory-protected module (PR:L), and kernel-mode threads and any system not using loadable memory-protected modules are unaffected. A writable shared region granted to the module makes the corrupted target application data in every memory layout; otherwise what sits below the data region (alignment padding, byte-pool metadata, or the preceding allocation) depends on the module manager's layout.

All exploitability signals point to a locally-scoped, privilege-dependent flaw rather than a mass-exploitation threat. The vendor CVSS:4.0 vector is AV:L/AC:L/AT:N/PR:L/UI:N (CVSS-B 7.0 High): exploitation is local, low-complexity, requires no attacker-uncontrolled conditions, but does require some privilege (PR:L) because the attacker must already control a loaded user-mode, memory-protected module on a Cortex-M Module Manager port. There is no CISA KEV listing and no EPSS score in the provided data, so there is no quantitative exploitation-probability signal to weigh - this is a gap, not evidence of low risk. No standalone public exploit is provided; the GHSA advisory does include a QEMU regression test that demonstrates the out-of-bounds write primitive, but that is a proof artifact bundled with the fix, not weaponized exploit code. The vuln.today decision label is 'this_week', consistent with a serious-but-not-emergency sandbox-escape primitive. Net: this is a genuine security-boundary defeat (user-mode module escaping MPU isolation to write privileged memory and hijack Handler-mode control flow), but its real-world reach is bounded by the requirement to already run an attacker-controlled module locally, so it is a real priority specifically for systems that load untrusted or third-party ThreadX modules, and considerably lower risk where all loaded modules are trusted. Impact asymmetry is notable: integrity and availability are High (VI:H/VA:H) while confidentiality is only Low (VC:L), matching a primitive that chiefly corrupts/controls rather than discloses.

On a Cortex-M ThreadX device using the Module Manager, an attacker who controls a loaded user-mode memory-protected module sets its process stack pointer about 32 bytes above the start of its data region or a granted writable shared region. When PendSV preempts the thread in privileged Handler mode, it saves registers downward from that unchecked pointer, writing up to eight attacker-chosen words plus an EXC_RETURN value into privileged memory immediately below the region; on the next switch-in PendSV reloads those words and branches to the attacker-supplied EXC_RETURN. No public exploit is identified, though the advisory ships a QEMU regression test that triggers the primitive.