Zephyr RTOS CVE-2026-10686

Exploitation requires the target Zephyr device to be built with CONFIG_NET_ROUTE enabled - this is the default when CONFIG_NET_IPV6_NBR_CACHE is set in the Kconfig - and to be actively functioning as an IPv6 router in a multi-hop network. Cross-interface exploitation (the on-link path, affecting all releases through v4.4.1 including v4.3.1) additionally requires CONFIG_NET_ROUTING to be enabled. The attacker must be on-path in the network and able to induce or exploit a transient L3 IPv6 routing loop between the Zephyr device and at least one adjacent router; this limits practical exploitation to network-adjacent or man-in-the-middle positions rather than arbitrary remote attackers. IPv4 is not affected in any released Zephyr version because the IPv4 forwarding path (route_ipv4.c) was never included in a release prior to the fix landing on main. Devices operating solely as end-hosts - not functioning as IPv6 routers - cannot be reached through the vulnerable forwarding path regardless of build configuration.

The NVD CVSS 7.5 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects a straightforward network-reachable DoS with no authentication, but this overstates ease of exploitation: the attack requires the attacker to be on-path and able to induce or exploit a transient L3 routing loop, which is a meaningful precondition not captured by AC:L. EPSS at 0.25% (16th percentile) is very low, consistent with the architectural specificity of the attack. SSVC confirms exploitation as none, the attack is not automatable, and technical impact is partial - collectively indicating low near-term exploitation priority. The flaw is present only in Zephyr devices built with routing enabled (CONFIG_NET_ROUTE, default when CONFIG_NET_IPV6_NBR_CACHE is set), acting as live IPv6 routers, so the effective attack surface is narrower than the CVSS score implies. IPv4 is unaffected in any released version. For deployments where Zephyr devices forward IPv6 traffic in multi-hop topologies - industrial IoT gateways, mesh network nodes - the risk is real and patching is warranted; for single-hop or non-routing deployments the vulnerability is unreachable. The AC:L assignment in the NVD vector is debatable given the on-path and loop-induction prerequisites; defenders should factor this into prioritisation.

An attacker positioned on-path between two Zephyr-based IPv6 routers manipulates routing advertisements or exploits a misconfigured network topology to establish a transient L3 routing loop between the Zephyr forwarder and an adjacent router. Once the loop exists, injecting unicast IPv6 packets into it causes the Zephyr device to forward them indefinitely without decrementing the hop limit, rapidly saturating the device CPU and link bandwidth; because hop-limit expiry never fires, standard loop-detection and path-discovery mechanisms (e.g., ICMPv6 Time Exceeded) are also defeated. No public proof-of-concept code has been identified; the attack requires on-path network positioning and the ability to create or exploit a routing loop condition.