Zephyr RTOS CVE-2026-10773

Exploitation requires two concurrent conditions: (1) the target Zephyr firmware must be compiled with CONFIG_NET_DHCPV4_LOG_LEVEL_DBG enabled, a non-default Kconfig setting that is absent in release and production builds; (2) the attacker must have Layer-2 adjacency to the target device, either as a legitimate participant on the same link or via a spoofed DHCP reply - DHCP is link-local (UDP broadcast), so the attacker cannot reach the client from a routed network without a relay. Exploitation is limited by the non-default debug configuration requirement: the vulnerable code path (NET_DBG log statement) is compiled out or skipped at non-debug log levels, making standard production firmware immune regardless of Zephyr version. No authentication by the attacker is required; no user interaction on the device is needed. The attack does not require knowledge of any secret, key, or internal state beyond the ability to send a UDP packet with a crafted DHCP option.

The NVD-assigned CVSS 3.1 score of 5.4 (AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L) reflects adjacent-network reachability and dual confidentiality/availability impact, but the AC:L rating overstates ease of exploitation because it does not capture the mandatory non-default build-time prerequisite (CONFIG_NET_DHCPV4_LOG_LEVEL_DBG). In practice, production Zephyr firmware is built with release-level logging; a device must be deliberately compiled with debug logging active for this code path to be reachable at runtime. An independent assessment of AC:H better represents the real exploitation bar. No EPSS data was provided. The CVE is not in the CISA KEV catalog and no POC has been identified, confirming this has not been exploited at scale. The primary real-world scenario is a development or test device with debug builds exposed on an untrusted network segment - a configuration edge case, not a mainstream deployment risk. The availability impact (crash of the DHCPv4 client, potentially the device) is the more likely outcome; information disclosure via log output of a garbage pointer value is a secondary concern requiring log capture by the attacker.

An attacker already positioned on the same Layer-2 network segment as a Zephyr device running a debug build sends a crafted DHCP OFFER or ACK packet containing a MESSAGE TYPE option (option 53) with a value between 9 and 31 (on a 32-bit target). The faulty bounds check passes because sizeof of the pointer array returns 32, the value indexes past the 8-element name table, and the resulting garbage pointer is dereferenced by the debug log's %s handler, crashing the DHCPv4 client or printing adjacent memory content to the log. No authentication or special tooling is required beyond the ability to inject raw Ethernet frames on the target's link, achievable via ARP spoofing or a rogue DHCP server.