CVE-2026-10686
PoC moderateInfinite IPv6 forwarding loop in Zephyr RTOS enables denial-of-service attacks
Zephyr's IPv6 forwarding path re-sends routed unicast packets without ever decrementing the IPv6 hop limit, as RFC 8200 requires, in both branches of ipv6_route_packet() in subsys/net/ip: the explicit-route path (net_route_packet()) and the on-link cross-interface path (net_route_packet_if()). Any Zephyr build acting as an IPv6 router — with CONFIG_NET_ROUTE (enabled by default when CONFIG_NET_IPV6_NBR_CACHE is set) and, for cross-interface routing, CONFIG_NET_ROUTING — will relay looping packets indefinitely, and an on-path attacker who can induce or exploit a transient Layer-3 loop turns it into a permanent forwarding storm. The attacker gains an availability-only denial of service (CVSS 3.1 7.5, high impact): CPU and bandwidth exhaustion on the forwarder and adjacent links, plus defeat of path-discovery and loop diagnostics that rely on hop-limit expiry; confidentiality and integrity are unaffected. All Zephyr releases from v1.8.0 through v4.4.1 are affected (v1.8.0 introduced net_route_packet(), v2.2.0 added net_route_packet_if(), and v4.3.1 carries only the explicit-route fix), while IPv4 forwarding is unreachable in any released version. No in-the-wild exploitation is known (EPSS 0.3% over 30 days, not in CISA KEV), but a public advisory with PoC reference is available (GHSA-4cg6-6jc4-2r6h).
What to do: Update to a Zephyr release containing both main-branch fixes (commits 7d8f1afa7345 for the explicit-route path and 589eadc74efa for the on-link path), or backport those commits. When auditing v4.4.1-or-earlier configurations, look for CONFIG_NET_ROUTE and CONFIG_NET_ROUTING — note that CONFIG_NET_IPV6_FORWARDING and CONFIG_NET_IPV4_FORWARDING were introduced after v4.4.0 and do not exist in affected releases — and disable IPv6 routing on devices that do not need to forward traffic as an interim mitigation. IPv4-only deployments are unaffected.
| Zephyr Project Zephyr | v1.8.0 through v4.4.1 inclusive (v4.3.1 carries only the explicit-route fix and remains affected); IPv4 forwarding is not affected in any release |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Zephyr's IPv6 forwarding path re-sent routed unicast packets without ever decrementing the IPv6 hop limit. Both routing branches of ipv6_route_packet() (subsys/net/ip) were affected: the explicit-route path (net_route_packet()) and the on-link cross-interface path (net_route_packet_if()). Each set the packet forwarding flag and called net_send_data() 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 CONFIG_NET_ROUTE (enabled by default when CONFIG_NET_IPV6_NBR_CACHE is set), together with CONFIG_NET_ROUTING for cross-interface routing. Note that CONFIG_NET_IPV6_FORWARDING and CONFIG_NET_IPV4_FORWARDING — 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 CONFIG_NET_ROUTE and CONFIG_NET_ROUTING. IPv4 is not affected in any release. The IPv4 forwarding path (net_route_ipv4_packet() in route_ipv4.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 net_route_packet() and v2.2.0 added net_route_packet_if(), 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).
- Vendors
- zephyrproject
- Products
- zephyr
- Weakness
- CWE-835
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.