Eclipse ThreadX LevelX EUVD-2026-89201

Exploitation requires that the device mount an attacker-controlled or attacker-modified NAND flash image through LevelX's lx_nand_flash_open() entry point; the trigger is a malformed on-flash metadata count field that the AI-generated parser (noted as partly Copilot/Sonnet 4.6 generated) fails to bounds-check. No authentication or user interaction is needed once the image is presented (PR:N/UI:N), but the attack vector is local (AV:L) - the attacker must be able to supply the flash contents, e.g. via removable/attached NAND media, a tampered firmware or OTA image, or a supply-chain/provisioning substitution. This is the primary limiting factor: products that only ever mount flash images produced in a trusted internal supply chain are not realistically reachable, whereas devices accepting externally-sourced or field-swappable NAND media are directly exposed. Impact is highest on bare-metal or non-memory-protected targets where the hijacked function pointer yields code execution rather than a fault.

This is a genuinely serious flaw whose real-world risk hinges almost entirely on one gating condition: the attacker must get the device to mount a NAND flash image they control. The vendor CVSS 4.0 vector (8.6) is explicitly local (AV:L) with no privileges or user interaction (PR:N/UI:N) and full triple-impact (VC:H/VI:H/VA:H), which is internally consistent - this is not a network-reachable bug despite the high score, so it should not be triaged like a remote RCE. The technical impact is unusually strong and well-substantiated: the description reports a demonstrated control-flow hijack with RIP set to a full 8-byte attacker-chosen value, register-verified, and reproduced verbatim under AddressSanitizer at HEAD 9f1cfdc - i.e., the vendor has a working reproduction, not a theoretical write primitive. No EPSS score, CISA KEV entry, or public exploit indicator is present in the supplied intelligence, so at analysis time there is no public exploit identified and no evidence of active exploitation; the vendor's own ASan reproduction is a proof-of-concept in the research sense but is not published exploit code in the feed. The conflict to flag for defenders is scope-of-reach versus impact: SSVC-style reasoning would rate technical impact 'total' but automatability 'no' and exploitation 'none', because the local, image-supply prerequisite makes this targeted rather than wormable. Net: high priority for any product that mounts externally-sourced or removable NAND media, but a lower operational priority where flash images are provisioned only in a trusted supply chain.

An attacker supplies a maliciously crafted NAND flash image - via removable/attached flash media, a compromised firmware/OTA image, or a manufacturing/supply-chain substitution - that the device mounts with lx_nand_flash_open(). The FTL metadata parser trusts an on-flash count field without bounds-checking, driving an out-of-bounds heap write that overwrites a driver function pointer in the LevelX control block; when that pointer is later invoked, execution jumps to an attacker-chosen 8-byte address. The vendor has demonstrated this end-to-end under ASan with a register-verified RIP hijack, so a reliable exploit is realistic, though no public exploit code appears in the supplied data.