Zephyr RTOS CVE-2026-18418

Requires all of: CONFIG_ZBUS_PROXY_AGENT_IPC built into the firmware; logging enabled at warning level or above (the default); and the attacker holding control over the firmware of a peer domain bound to the ipc_service endpoint - typically a second core on the same SoC. The attacker then sends a frame of exactly sizeof(struct zbus_proxy_msg) bytes with either an out-of-range message_size or a channel_name[] array containing no NUL byte, hitting the rejection path that logs the non-terminated name. Limiting factors: exploitation is local to the SoC's inter-domain IPC (not remotely reachable), demands high privilege in the form of a compromised/malicious peer core (PR:H), and is void if the proxy-agent IPC Kconfig is disabled or logging is below warning level.

This is a genuinely low-priority issue, and the multiple signals agree rather than conflict. The CVSS 3.1 base score is 3.4 (Low) with vector AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:L, which my independent reading of the description confirms: the vector is local (an IPC endpoint on the same SoC, not network), and exploitation requires PR:H because the attacker must already control the firmware of a peer domain - typically a second core on the same chip. There is no CISA KEV listing and no public exploit identified at time of analysis, and no EPSS score was provided in the input. The technical impact is bounded disclosure of a small amount of adjacent memory (IPC thread stack with the icmsg backend, or shared vring memory with rpmsg backends) into the receiving domain's log sink, with a possible fatal fault - the log packager's own -ENOSPC bound prevents the out-of-bounds read from ever becoming a write. In short, this is a low-CVSS AND low-real-risk issue: it requires a strong precondition (a compromised or malicious peer core), yields only limited info disclosure or a crash, and has no evidence of exploitation. Note one dependency the raw CVSS does not capture: exploitability also requires CONFIG_ZBUS_PROXY_AGENT_IPC to be built and logging at warning level or above (the default), so non-default build configurations may not be affected at all.

In a multi-core Zephyr SoC where one core runs attacker-controlled firmware, the malicious core places a frame of sizeof(struct zbus_proxy_msg) bytes on the bound ipc_service endpoint with either an out-of-range message_size or a channel_name[] array containing no NUL byte. The receiving domain rejects the frame but logs its channel name with a plain %s, causing strlen() to walk past the fixed-size buffer and render adjacent stack or shared-vring bytes into the log, disclosing a small amount of neighboring memory (or faulting if the scan leaves a mapped region). No public exploit code exists, and the attack requires prior control of the peer domain's firmware.