Zephyr RTOS CVE-2026-10684

Exploitation requires two concurrent prerequisites. First, the attacker must hold high-privilege local shell access on the Zephyr device - the vulnerability is only reachable via the 'coredump print' shell command, which requires both the Zephyr shell subsystem (CONFIG_SHELL) and the coredump shell extension (CONFIG_DEBUG_COREDUMP_SHELL) to be compiled into the firmware; these are debug/development features not typically enabled in production builds. Second, the attacker must be able to stage or corrupt the stored coredump in the flash or in-memory backend with a tgt_code field value >= 7; normal device crash handling always produces in-range tgt_code values, so triggering the flaw requires deliberate manipulation of coredump storage rather than simply inducing a crash. Exploitation is additionally bounded by the fact that the information disclosed (arbitrary char* dereferenced as a string) is visible only to the privileged shell user who is already trusted to view coredump data. These conditions collectively limit realistic exploitation to insider-threat or supply-chain scenarios involving devices with debug firmware.

The CVSS 3.1 base score of 3.0 (AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:L) correctly characterises the constrained attack surface. Local access vector (AV:L) confines exploitation to the device itself; high privilege requirement (PR:H) means an attacker must already hold privileged shell credentials; and high attack complexity (AC:H) reflects that triggering the flaw requires deliberate staging or corruption of the coredump storage backend with a crafted tgt_code - a normal device crash produces only in-range values and will never trigger this path. No CISA KEV listing exists, no public POC has been identified, and no EPSS score was provided in the source data. The vulnerability lives in a debug/diagnostic subsystem (CONFIG_DEBUG_COREDUMP_SHELL) that is typically disabled in production firmware builds, further reducing exposure. Impact is limited to partial confidentiality loss (C:L) - leaking a string of device memory to a shell already controlled by the privileged attacker - or a local crash (A:L). For the vast majority of Zephyr deployments this is a low-priority informational finding; it warrants attention only in development or field-debug firmware images where privileged shell access is granted to potentially untrusted operators.

A privileged developer or operator with local Zephyr shell access on an affected device (v4.2.0-v4.4.0) writes a crafted coredump blob containing a tgt_code value such as 0x0200 (512) directly to the device's coredump flash backend using available debug tooling, then issues the 'coredump print' shell command. The print_coredump_hdr() function uses 512 as an unchecked array index into the 7-element coredump_target_code2str[], reads a char* value from 505 entries past the array end, and shell_print() walks that pointer as a C string - potentially printing several bytes of adjacent rodata, stack, or heap content to the shell terminal.