SEPTEMBER 15, 2026
Live Feed
Back to database
Case File

CVE-2026-10684

LOW · CVSS 3 EPSS 0.10% Public Exploit

Source: NVD + CISA KEV + EPSS · Published 2026-07-29 · Last synced 2026-08-28

CyberRota Analysis

AI-Generated

The vulnerability exists in the coredump handling of the Zephyr operating system, where the tgt_code field can be used as an index into a fixed-size array without proper bounds checking. This flaw may lead to out-of-bounds memory access, potentially disclosing sensitive device memory or causing a crash if the pointer is unmapped. Organizations using affected versions of Zephyr should prioritize remediation, especially those with local shell access that could exploit this vulnerability through manipulated coredumps.

Public Exploit Signal

A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.

Note: these links are listed for security research and verification purposes only.

CVE
CVE-2026-10684
Severity
LOW
CVSS
3
EPSS
0.10%

Original NVD Description

In subsys/debug/coredump/coredump_shell.c, print_coredump_hdr() used the 16-bit tgt_code field of a stored Zephyr coredump header directly as an index into coredump_target_code2str[], a fixed 7-element array of string pointers, with no bounds check. A stored coredump whose tgt_code is >= 7 causes an out-of-bounds read of a char* up to ~64K entries past the array; that value is passed as the %s argument to shell_print, which dereferences and walks it as a string. The result is either disclosure of device memory contents to the shell user or a crash when the out-of-bounds pointer is unmapped. The defect is reached via the coredump print shell command (cmd_coredump_print_stored_dump -> pretty_print_coredump -> parse_and_print_coredump -> print_coredump_hdr). The tgt_code field is device-generated and in-range during normal crash handling, so triggering requires local shell access plus the ability to stage or corrupt the stored coredump in the flash/in-memory backend. Introduced in v4.2.0 (commit 13abd7fe730) and present through v4.4.0; fixed by clamping out-of-range codes to the 'unknown' (index 0) entry.