Skip to main content
VulnerabilityPublished

CVE-2026-0648: Eclipse ThreadX · Incorrect Check of Function Return Value

Affects Eclipse ThreadXSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High.

Data as of 26 Oct 2026, 10:12 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
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:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 27 Jan 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
Eclipse FoundationEclipse ThreadXAffected
  • >=6.1.7 <=6.4.3
Fixed in–
GitHubeclipse-threadx/threadxpkg:github/eclipse-threadx/threadxOther threatsAffected
  • =6.1.7
Fixed in–
GitHubEclipse ThreadXpkg:github/Eclipse ThreadXOther threatsAffected
  • >=6.1.7 <=6.4.3
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

  1. Immediate mitigation should include auditing all embedded and IoT devices running Eclipse ThreadX 6.1.7 to identify vulnerable instances.
  2. Implement strict access controls to limit local access to trusted personnel and processes, reducing the risk of exploitation.
  3. Monitor device logs and behavior for signs of repeated counter pool exhaustion or abnormal crashes indicative of exploitation attempts.
  4. Where possible, isolate vulnerable devices from critical networks to contain potential denial-of-service impacts.
  5. Engage with Eclipse Foundation or device vendors to obtain patches or updates addressing this vulnerability as soon as they become available.
  6. Consider implementing runtime memory protection mechanisms or watchdog timers to detect and recover from HardFaults or memory corruption events.
  7. For new deployments, evaluate upgrading to newer ThreadX versions or alternative RTOS solutions that have addressed this issue.
  8. 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.

References

Community reviews

Loading reviews…