Eclipse ThreadX CVE-2025-55080

Exploitation requires ALL of the following: (1) the device runs Eclipse ThreadX before 6.4.3; (2) ThreadX memory protection (the MPU/module memory-protection feature) is ENABLED - the advisory explicitly scopes the flaw to 'when memory protection is enabled', so devices without memory protection are not in scope; (3) the attacker already has local, low-privilege code execution on the device (CVSS PR:L, AV:L), such as control of a less-privileged ThreadX module from which to issue system calls; and (4) the attacker can craft syscall parameters that evade the insufficient validation (reflected by AT:P). Limiting factors: this is not remotely reachable without a prior foothold, requires the non-universal memory-protection configuration, and depends on the presence of an exploitable syscall path - these substantially narrow realistic exploitation despite full read/write impact.

This is a moderate, defense-in-depth vulnerability rather than an urgent, widely-exploitable priority. The CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:L) describes a LOCAL attack that already requires low-level privileges - i.e. the attacker must already be executing code on the device, typically within a less-privileged ThreadX module/thread - and additionally carries an attack requirement (AT:P) meaning the target must be running with memory protection (MPU) enabled, the exact feature this flaw subverts. All three independent prioritization signals point the same, consistent direction: EPSS is very low at 0.14% (3rd percentile), the CVE is NOT in CISA KEV, and no public exploit code was identified in the provided data. There is no conflict among the signals here. The 7.2 'High' score is driven by VC:H/VI:H (full confidentiality and integrity impact - arbitrary read/write of kernel/other-module memory), not by ease of reach; the local vector and pre-existing privilege requirement sharply constrain real-world risk. The realistic concern is privilege escalation / sandbox-escape within an already-compromised embedded device, not remote mass exploitation. One caveat: the input provides only a CVSS 4.0 vector and no NVD-published CVSS 3.1 score, so cross-framework comparison relies on a single vendor-supplied vector.

An attacker who has already achieved code execution inside a low-privileged ThreadX module on a device running with memory protection (MPU) enabled issues a system call with crafted/malformed parameters. Because syscall parameter validation is insufficient, the kernel acts on attacker-controlled pointers, giving the attacker an arbitrary read/write primitive to access protected kernel or other-module memory and escalate privileges. No public proof-of-concept was identified at the time of analysis; this would require local execution and a non-default memory-protection configuration.