Zephyr RTOS EUVD-2026-112266

Exploitation requires the Zephyr device (4.1.0-4.4.2) to be built and deployed as a packet forwarder or tunnel endpoint: specifically with CONFIG_NET_IPV4_FORWARDING/CONFIG_NET_IPV6_FORWARDING enabled forwarding from a non-Ethernet L2 (802.15.4/OpenThread or PPP) out to Ethernet/Wi-Fi, OR IPv6 multicast forwarding of RX-slab clones, OR the IPIP tunnel sending an outer-IP packet over an attached Ethernet interface. The in-place header path must also be enabled via CONFIG_NET_L2_ETHERNET_RESERVE_HEADER, which ships default-y on nRF54L Wi-Fi zero-copy TX (NRF_WIFI_ZERO_COPY_TX) and on NXP Wi-Fi. The out-of-bounds write only actually occurs in production builds compiled WITHOUT CONFIG_ASSERT and WITHOUT CONFIG_NET_BUF_HARDENING (otherwise the push is asserted or returns NULL). Key limiting factors: plain Ethernet-to-Ethernet forwarding is NOT affected because ethernet_recv() pulls the header and leaves headroom; the attacker controls neither the written bytes nor the offset; and the whole vulnerable path depends on a non-default forwarding/tunnel configuration on specific platforms.

Signals are mostly consistent toward a moderate, availability-focused issue rather than an emergency. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H, base 6.5) describes an unauthenticated, network-reachable but high-complexity flaw whose dominant impact is availability (crash/DoS) with only limited integrity impact and no confidentiality loss - matching the advisory's own statement that the attacker controls neither the written bytes nor the offset, so the outcome is memory corruption/crash/heap inconsistency, not controlled code execution. The vuln.today Decision label is this_month, not act_now or emergency. No EPSS score is provided, there is no CISA KEV listing (not actively exploited), and no public exploit identified at time of analysis - the only references are the vendor patch commit and the GHSA advisory, not PoC exploit code. The one notable conflict is the input 'RCE' tag, which is directly contradicted by the vendor's own impact analysis (uncontrolled write, no code execution); treat RCE as a mislabel, not a confirmed capability. AC:H is well justified here not by any race or timing but by the configuration dependency: the device must be acting as a forwarder/tunnel endpoint and be built without assertions. Net: a real but conditional issue best handled on a normal monthly patch cadence, not an actively-exploited priority.

A Zephyr device configured to forward or tunnel traffic (e.g. IPv4/IPv6 forwarding from an 802.15.4/OpenThread/PPP interface out to Ethernet/Wi-Fi, IPv6 multicast forwarding, or an IPIP tunnel over Ethernet) receives attacker traffic from a remote or adjacent source. When the forwarded packet - allocated by a non-Ethernet L2 and therefore lacking reserved Ethernet headroom - is handed to Ethernet TX, net_buf_push writes 14 bytes (18 with VLAN) before the fragment's data block, corrupting a neighbouring buffer or allocator metadata. No public exploit is identified at time of analysis; the realistic result is a crash or heap inconsistency (DoS), not reliable code execution.