CVE-2026-10686: Missing hop-limit decrement on IPv6 forwarding path allows unbounded packet looping (DoS) in Zephyr routers
Zephyr's IPv6 forwarding path re-sent routed unicast packets without ever decrementing the IPv6 hop limit. Both routing branches of ipv6routepacket() (subsys/net/ip) were affected: the explicit-route path (netroutepacket()) and the on-link cross-interface path (netroutepacketif()). Each set the packet forwarding flag and called netsenddata() with the hop limit untouched and no expiry check.
Per RFC 8200 the hop-limit decrement is the mechanism that bounds packet lifetime and terminates routing loops; without it, a device acting as an IPv6 router relays looping packets indefinitely. An on-path attacker who can induce or exploit a transient L3 loop turns it into a permanent forwarding storm, causing CPU/bandwidth resource exhaustion (availability DoS) on the forwarder and adjacent links; path-discovery and loop diagnostics that rely on hop-limit expiry are also defeated.
Affected configurations. In every affected release the forwarding path is reached via CONFIGNETROUTE (enabled by default when CONFIGNETIPV6NBRCACHE is set), together with CONFIGNETROUTING for cross-interface routing. Note that CONFIGNETIPV6FORWARDING and CONFIGNETIPV4FORWARDING — which appear in the fix and in this advisory's evidence notes — were introduced after v4.4.0, when the routing options were split and renamed; they do not exist in any affected release. When auditing a v4.4.1-or-earlier configuration, look for CONFIGNETROUTE and CONFIGNETROUTING.
IPv4 is not affected in any release. The IPv4 forwarding path (netrouteipv4packet() in routeipv4.c) was added after v4.4.0 and has never shipped in a release. Its TTL decrement and IPv4 header-checksum recomputation landed on main as part of the same fix, so the evidence notes below discuss it, but no released version is reachable by way of IPv4.
Affected releases are v1.8.0 through v4.4.1: v1.8.0 introduced netroutepacket() and v2.2.0 added netroutepacketif(), and neither decremented the hop limit. v4.3.1 carries the explicit-route fix but not the on-link one, so it is affected as well. Fixed on main by 7d8f1afa7345 (explicit-route path) and 589eadc74efa (on-link path).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
zephyr (net routing)to a version that resolves this vulnerability.Patch 7d8f1afa7345 - Upgrade
Upgrade
zephyr (net routing)to a version that resolves this vulnerability.Patch 589eadc74efa - Configuration
If auditing an affected build (v1.8.0 through v4.4.1 or earlier), disable CONFIG_NET_ROUTE (it is enabled by default when CONFIG_NET_IPV6_NBR_CACHE is set) to prevent the IPv6 forwarding path that calls net_send_data() without hop-limit expiry.
Zephyr networking CONFIG_NET_ROUTE = disable - Configuration
If auditing an affected build (v1.8.0 through v4.4.1 or earlier), disable CONFIG_NET_ROUTING to prevent cross-interface IPv6 routing that is affected via net_route_packet_if().
Zephyr networking CONFIG_NET_ROUTING = disable
Event History
Frequently Asked Questions
What is the severity of CVE-2026-10686?
CVE-2026-10686 has a medium severity rating of 5.8.
What type of vulnerability is CVE-2026-10686?
CVE-2026-10686 is a denial-of-service (DoS) vulnerability caused by unbounded packet looping due to missing hop-limit decrement on the IPv6 forwarding path.
How do I fix CVE-2026-10686?
To fix CVE-2026-10686, update your Zephyr Project Zephyr to the latest version that addresses this hop-limit decrement issue.
Which software is affected by CVE-2026-10686?
CVE-2026-10686 affects the Zephyr Project Zephyr.
What is the impact of CVE-2026-10686?
The impact of CVE-2026-10686 is that it can lead to unbounded packet looping, resulting in denial-of-service conditions on affected Zephyr routers.