Eclipse ThreadX EUVD-2026-89172

Requires the attacker to already be executing code in the NON-SECURE world of an Arm TrustZone-M-enabled device running Eclipse ThreadX, and the device must actually expose TrustZone-M non-secure callable (NSC) entry functions that accept caller-supplied pointers. This is a local, code-execution-prerequisite condition (AV:L, PR:L): there is no network vector and no remote-unauthenticated path. Limiting factors: only devices built with TrustZone-M secure/non-secure separation and these NSC entry points are affected; a pure single-world ThreadX build without TrustZone-M NSC surfaces is not exposed. No user interaction is needed once the non-secure foothold exists.

This is a genuine but access-gated privilege/trust-boundary flaw, not an internet-facing critical. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N, base 8.4) makes the constraints explicit: exploitation requires the attacker to already be executing code in the non-secure world of an Arm TrustZone-M device, i.e. a local foothold (PR:L, AV:L), with no user interaction. Given that foothold, the flaw is high value: it breaks the core TrustZone-M security-authority boundary and yields VC:H/VI:H (secure-memory disclosure and a corruption primitive) that may recover cryptographic key material - the single most impactful thing this boundary is meant to protect. No EPSS score, no CISA KEV listing, and no public POC were supplied, so there is no evidence of active or automated exploitation; scoring this on real-world signals it reads as targeted/opportunistic against embedded devices rather than widespread mass exploitation. The main tension to verify: the tag is 'Information Disclosure' and CWE is CWE-200, but the description and the VI:H metric describe a memory-CORRUPTION primitive as well - this is not purely a confidentiality bug, and defenders should treat it as an integrity threat to the secure world too.

An attacker who has already achieved code execution in the non-secure world of a TrustZone-M device (e.g. via a compromised non-secure application or firmware component) calls a non-secure callable (NSC) entry function and passes a pointer that actually references secure memory. Because the secure firmware dereferences the attacker-controlled pointer without validating that it points to non-secure memory, the attacker reads back (or corrupts) secure-world contents, potentially extracting cryptographic keys. No public exploit code was identified at the time of analysis, and no user interaction is required once the non-secure foothold exists.