CVE-2026-10686: dos in zephyrproject zephyr
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).
AI Analysis
Technical Summary
The vulnerability in Zephyr's IPv6 forwarding path arises because the hop limit field in IPv6 packets is not decremented during forwarding in two routing branches: the explicit-route path (net_route_packet()) and the on-link cross-interface path (net_route_packet_if()). According to RFC 8200, the hop limit is essential to prevent packets from looping indefinitely. Without decrementing the hop limit, a device acting as an IPv6 router can forward looping packets endlessly, causing CPU and bandwidth exhaustion (a denial of service). The affected versions are from 1.8.0 through 4.4.1, with the explicit-route path fix merged in version 4.3.1 but the on-link path fix only present after 4.4.1. IPv4 forwarding is unaffected in released versions. The vulnerability requires specific configuration options (CONFIG_NET_ROUTE and CONFIG_NET_ROUTING) to be enabled.
Potential Impact
An on-path attacker capable of inducing or exploiting a transient Layer 3 routing loop can cause packets to be forwarded indefinitely without hop limit expiration. This results in a permanent forwarding storm that exhausts CPU and bandwidth resources on the affected device and adjacent network links, causing a denial of service. Additionally, path-discovery and loop diagnostics relying on hop-limit expiry are disrupted. There is no impact on confidentiality or integrity, only availability.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability was fixed on the main development branch after version 4.4.1, but no official patch release is indicated. Users should monitor Zephyr project advisories for an official fix release. In the meantime, review configurations to understand if CONFIG_NET_ROUTE and CONFIG_NET_ROUTING are enabled, as these enable the vulnerable forwarding paths. IPv4 forwarding is not affected in released versions.
CVE-2026-10686: dos in zephyrproject zephyr
Description
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).
CVSS v3.1
Score 5.8medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in Zephyr's IPv6 forwarding path arises because the hop limit field in IPv6 packets is not decremented during forwarding in two routing branches: the explicit-route path (net_route_packet()) and the on-link cross-interface path (net_route_packet_if()). According to RFC 8200, the hop limit is essential to prevent packets from looping indefinitely. Without decrementing the hop limit, a device acting as an IPv6 router can forward looping packets endlessly, causing CPU and bandwidth exhaustion (a denial of service). The affected versions are from 1.8.0 through 4.4.1, with the explicit-route path fix merged in version 4.3.1 but the on-link path fix only present after 4.4.1. IPv4 forwarding is unaffected in released versions. The vulnerability requires specific configuration options (CONFIG_NET_ROUTE and CONFIG_NET_ROUTING) to be enabled.
Potential Impact
An on-path attacker capable of inducing or exploiting a transient Layer 3 routing loop can cause packets to be forwarded indefinitely without hop limit expiration. This results in a permanent forwarding storm that exhausts CPU and bandwidth resources on the affected device and adjacent network links, causing a denial of service. Additionally, path-discovery and loop diagnostics relying on hop-limit expiry are disrupted. There is no impact on confidentiality or integrity, only availability.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability was fixed on the main development branch after version 4.4.1, but no official patch release is indicated. Users should monitor Zephyr project advisories for an official fix release. In the meantime, review configurations to understand if CONFIG_NET_ROUTE and CONFIG_NET_ROUTING are enabled, as these enable the vulnerable forwarding paths. IPv4 forwarding is not affected in released versions.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- zephyr
- Date Reserved
- 2026-06-02T15:26:24.115Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a6cf74dbf32cb7a34294add
Added to database: 07/31/2026, 19:28:13 UTC
Last enriched: 07/31/2026, 19:36:30 UTC
Last updated: 07/31/2026, 21:26:40 UTC
Views: 2
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.