CVE-2026-0648: Eclipse ThreadX · Incorrect Check of Function Return Value
Affects Eclipse ThreadXSource CVE Database V5
Not known to be exploited · CVSS 7.8 High.
Data as of 26 Oct 2026, 10:12 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 27 Jan 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Eclipse FoundationEclipse ThreadX | Affected
| Fixed in– |
GitHubeclipse-threadx/threadxpkg:github/eclipse-threadx/threadxOther threats | Affected
| Fixed in– |
GitHubEclipse ThreadXpkg:github/Eclipse ThreadXOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
- Immediate mitigation should include auditing all embedded and IoT devices running Eclipse ThreadX 6.1.7 to identify vulnerable instances.
- Implement strict access controls to limit local access to trusted personnel and processes, reducing the risk of exploitation.
- Monitor device logs and behavior for signs of repeated counter pool exhaustion or abnormal crashes indicative of exploitation attempts.
- Where possible, isolate vulnerable devices from critical networks to contain potential denial-of-service impacts.
- Engage with Eclipse Foundation or device vendors to obtain patches or updates addressing this vulnerability as soon as they become available.
- Consider implementing runtime memory protection mechanisms or watchdog timers to detect and recover from HardFaults or memory corruption events.
- For new deployments, evaluate upgrading to newer ThreadX versions or alternative RTOS solutions that have addressed this issue.
- Conduct thorough testing of device firmware to ensure error handling correctly interprets return values and prevents wild pointer dereferences.
Description
The vulnerability stems from an incorrect error-checking logic in the CreateCounter() function (in threadx/utility/rtos_compatibility_layers/OSEK/tx_osek.c) when handling the return value of osek_get_counter(). Specifically, the current code checks if cntr_id equals 0u to determine failure, but @osek_get_counter() actually returns E_OS_SYS_STACK (defined as 12U) when it fails. This mismatch causes the error branch to never execute even when the counter pool is exhausted. As a result, when the counter pool is depleted, the code proceeds to cast the error code (12U) to a pointer (OSEK_COUNTER *), creating a wild pointer. Subsequent writes to members of this pointer lead to writes to illegal memory addresses (e.g., 0x0000000C), which can trigger immediate HardFaults or silent memory corruption. This vulnerability poses significant risks, including potential denial-of-service attacks (via repeated calls to exhaust the counter pool) and unauthorized memory access.