Eclipse ThreadX CVE-2025-55079

Exploitation requires the attacker to already execute or control code on the device that invokes ThreadX's thread-creation/priority-setting path (consistent with AV:L and PR:L), AND the specific case in which the maximum-priority check is not performed must be reached (reflected by AT:P, attack requirements present). Limiting factors: no network vector, no path to confidentiality or integrity impact (VC:N/VI:N) - only availability (VA:H); the defect is fixed in ThreadX 6.4.3, so only unpatched builds below that version are affected. Note that on a flat-memory RTOS without an enforced privilege boundary, the 'low privilege' prerequisite may be weaker in practice than on a general-purpose OS, so firmware that lets semi-trusted components create threads is more exposed.

Signals are consistent and point to a genuine but low-to-moderate priority issue. The CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:L/UI:N) describes a locally-exploitable flaw that requires an attacker already running low-privileged code on the device plus a specific runtime condition (AT:P) to be met - this is not a remote or unauthenticated bug. Impact is confined to availability (VA:H, with VC:N/VI:N), aligning with the description's 'possible denial of service' via a thread obtaining higher-than-intended priority (CWE-770, missing resource/limit check). EPSS is low (0.17%, 6th percentile) and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation; however, public exploit/advisory material exists (the Eclipse GHSA security advisory is flagged as an exploit reference). Net: a real, patch-worthy correctness/availability defect in an RTOS, but the local-access and conditional requirements plus availability-only impact make it a lower urgency than a network-facing or code-execution flaw. The main caveat is that CVSS 'local' and 'privileges' map awkwardly onto a bare-metal RTOS where there is often no OS privilege boundary - on such targets the practical barrier is simply the ability to run or influence thread-creation code, so operators should assess exploitability against their own firmware's trust model rather than the raw score.

An attacker able to run or influence low-privileged application code on a ThreadX-based device creates or configures a thread while the maximum-priority check is skipped, obtaining a thread priority higher than the design intended. That over-privileged thread starves or preempts critical tasks, degrading or hanging the real-time system (denial of service). Public advisory/exploit material exists, but exploitation still requires local code execution and the specific condition where the check is bypassed.