CVE-2026-0648
Memory Safety in Eclipse Threadx 6.1.7 – 6.4.5
Raw vector
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:HSummary
CVE-2026-0648 is a high-severity Incorrect Check of Function Return Value (CWE-253) vulnerability in Eclipse Threadx. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 1th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-0648 affects Eclipse ThreadX, specifically the CreateCounter() function in threadx/utility/rtos_compatibility_layers/OSEK/tx_osek.c within its OSEK compatibility layer. The vulnerability originates from flawed error-checking logic that inspects the return value of osek_get_counter(). The code treats a cntr_id of 0u as failure, but osek_get_counter() returns E_OS_SYS_STACK (12U) on failure, such as when the counter pool is exhausted. Consequently, the error-handling branch is bypassed, and the error code is cast to an OSEK_COUNTER pointer, yielding a wild pointer that enables writes to invalid memory addresses like 0x0000000C.
A local attacker with low privileges (PR:L) can exploit this under high attack complexity (AC:H), as indicated by the CVSS v3.1 score of 7.8 (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H). By repeatedly invoking operations to deplete the counter pool, the attacker triggers HardFaults for denial-of-service or induces silent memory corruption through out-of-bounds writes. This aligns with CWE-253 (Incorrect Check of Function Return Value) and CWE-787 (Out-of-bounds Write), potentially granting unauthorized memory access with changed scope impact.
Mitigation guidance is available in the security advisory at https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-xj75-fc68-h4rw, published on 2026-01-27.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-4817
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and code analysis can discover missing or incorrect return-value checks.
Documented development standards and tools can mandate verified checking of every function return value.
Security engineering principles include requirements for robust error checking of all function returns.
Input validation can structurally reject or sanitize data that would otherwise trigger an out-of-bounds write.
Memory-protection mechanisms limit the exploitability and blast radius of a successful out-of-bounds write.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly enforce proper error-handling and return-value checking during development.
Vulnerability scanning and recording can discover out-of-bounds write flaws so they can be remediated.
Patching or replacing vulnerable software directly eliminates known instances of this coding weakness.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development catches missing or incorrect return-value checks.
Secure SDLC mandates return-value checks and error handling, directly reducing CWE-253.
Application security requirements include robust error handling that mitigates incorrect return-value checks.
Secure architecture principles require defensive coding practices such as validating function results.
Secure coding explicitly demands checking return values, covering most of CWE-253.
Change management can enforce review gates that catch unsafe memory operations before deployment.