CVE-2026-10686: Zephyr IPv6 Forwarding DoS Vulnerability

CVE-2026-10686 Overview

CVE-2026-10686 is an infinite loop vulnerability [CWE-835] in the Zephyr real-time operating system's IPv6 forwarding path. The forwarder re-sends routed unicast packets without decrementing the IPv6 hop limit, violating RFC 8200. Both net_route_packet() (explicit-route path) and net_route_packet_if() (on-link cross-interface path) in subsys/net/ip/ipv6.c set the forwarding flag and call net_send_data() with the hop limit untouched and no expiry check. An attacker who induces a transient Layer 3 loop converts it into a permanent forwarding storm, exhausting CPU and bandwidth on the forwarder.

Critical Impact
A network-adjacent attacker can trigger sustained IPv6 forwarding loops that exhaust router CPU and link bandwidth, causing an availability denial of service on affected Zephyr-based devices.

Affected Products

Zephyr RTOS v1.8.0 through v4.4.1 (IPv6 forwarding path)
Zephyr v4.3.1 (carries only the explicit-route fix, still affected via the on-link path)
Configurations with CONFIG_NET_ROUTE and CONFIG_NET_ROUTING enabled

Discovery Timeline

2026-07-31 - CVE-2026-10686 published to NVD
2026-08-04 - Last updated in NVD database

Technical Details for CVE-2026-10686

Vulnerability Analysis

The defect lives in Zephyr's IPv6 forwarding logic under subsys/net/ip/. When ipv6_route_packet() selects a next hop, two branches relay the packet: net_route_packet() for explicit routes and net_route_packet_if() for on-link cross-interface delivery. Neither branch decrements the IPv6 hop limit, and neither performs an expiry check before invoking net_send_data().

RFC 8200 relies on the hop limit as the sole mechanism to bound packet lifetime and terminate routing loops. Without decrement, a Zephyr device acting as an IPv6 router forwards looped packets indefinitely. Path-discovery tooling and loop diagnostics that depend on hop-limit expiry also fail to converge.

IPv4 is not affected in any released version. The IPv4 forwarder net_route_ipv4_packet() in route_ipv4.c was added after v4.4.0 and has never shipped in a release.

Root Cause

Both IPv6 routing branches were introduced without the hop-limit decrement mandated by RFC 8200. net_route_packet() shipped in v1.8.0 and net_route_packet_if() shipped in v2.2.0; neither modified the outbound packet's hop limit. The forwarding flag was also set unconditionally, so the transmit path treated locally originated and forwarded traffic identically.

Attack Vector

An on-path attacker who can induce or exploit a transient Layer 3 loop, for example through a misconfigured neighbor, spoofed router advertisement, or crafted next-hop, converts the loop into a permanent forwarding storm. The affected Zephyr router relays the looping packet until link or CPU capacity is saturated. No authentication or user interaction is required.

// Security patch in subsys/net/ip/ipv6.c
// Only mark cross-interface traffic as forwarded so the hop-limit
// decrement path is exercised correctly.
			add_route(net_pkt_orig_iface(pkt), &src_ip, 128);
		}

+		if (IS_ENABLED(CONFIG_NET_IPV6_FORWARDING) &&
+		    net_pkt_orig_iface(pkt) != net_pkt_iface(pkt)) {
+			net_pkt_set_forwarding(pkt, true);
+		} else {
+			net_pkt_set_forwarding(pkt, false);
+		}
+
		ret = net_route_ipv6_packet(pkt, nexthop);
		if (ret < 0) {
			NET_DBG("Cannot re-route pkt %p via %s "

Source: Zephyr GitHub Commit 7d8f1afa7345

Detection Methods for CVE-2026-10686

Indicators of Compromise

Sustained high packet rates between two or more interfaces on a Zephyr-based router with identical IPv6 source and destination pairs.
IPv6 packets traversing the same forwarding device repeatedly with a static hop limit value across captures.
Abnormal CPU utilization on Zephyr networking threads coinciding with link saturation on adjacent segments.

Detection Strategies

Audit build configurations for CONFIG_NET_ROUTE and CONFIG_NET_ROUTING on Zephyr images at v4.4.1 or earlier to enumerate exposed devices.
Deploy passive traffic monitoring at aggregation points to flag IPv6 flows with non-decrementing hop limits crossing the same MAC address.
Correlate SNMP or telemetry counters for interface packet rate and drop rate against baseline forwarding volume.

Monitoring Recommendations

Collect and centralize Zephyr NET_DBG logs and interface counters into a security data lake for longitudinal analysis.
Alert on sudden increases in net_pkt allocation rate or forwarding-path invocations relative to steady-state traffic.
Instrument upstream switches with storm-control thresholds sized to Zephyr device link speeds so loops trigger operator alerts.

How to Mitigate CVE-2026-10686

Immediate Actions Required

Inventory all Zephyr-based devices running v1.8.0 through v4.4.1 that ship with CONFIG_NET_ROUTE enabled.
Rebuild affected firmware against Zephyr main including commits 7d8f1afa7345 and 589eadc74efa, then flash impacted devices.
Restrict IPv6 routing on Zephyr endpoints to trusted segments until patched firmware is deployed.

Patch Information

The defect is fixed on main by commit 7d8f1afa7345 (explicit-route path) and commit 589eadc74efa (on-link path). Both fixes introduce a CONFIG_NET_IPV6_FORWARDING gate so only genuine cross-interface traffic is marked as forwarded, and they add the hop-limit decrement in net_route_ipv6_packet(). See the Zephyr Security Advisory GHSA-4cg6-6jc4-2r6h for the full remediation record.

Workarounds

Disable IPv6 routing by unsetting CONFIG_NET_ROUTE and CONFIG_NET_ROUTING where the device does not need to forward traffic.
Constrain neighbor discovery inputs by isolating Zephyr routers on segments where router advertisements are filtered and validated upstream.
Apply upstream rate limiting and loop detection on switches adjacent to Zephyr forwarders to contain storms until firmware is updated.

bash

# Kconfig fragment: remove IPv6 routing on non-forwarding devices
# CONFIG_NET_ROUTE is not set
# CONFIG_NET_ROUTING is not set
# CONFIG_NET_IPV6_NBR_CACHE=y  # keep neighbor cache only if required