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).
Published: 2026-07-31
Score: 5.8 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

Zephyr’s IPv6 forwarding path does not decrement the hop‑limit on routed unicast packets, allowing packets that enter a routing loop to be forwarded indefinitely. This behavior enables an on‑path attacker to convert a transient Layer‑3 loop into a permanent forwarding storm, exhausting CPU and network bandwidth on the router and its adjacent links. The flaw therefore results in an availability denial of service; it does not provide confidentiality or integrity compromise. The weakness is a classic “Infinite Loop” error, corresponding to CWE‑835.

Affected Systems

The vulnerability affects Zephyr Project’s Zephyr RTOS in releases from v1.8.0 through v4.4.1. Systems that have IPv6 routing enabled – indicated by CONFIG_NET_ROUTE and CONFIG_NET_ROUTING – are at risk. The flaw is confined to IPv6; IPv4 forwarding was added after v4.4.0 and is not affected. All configurations that enable IPv6 forwarding as a router are potentially vulnerable.

Risk and Exploitability

The CVSS base score of 5.8 indicates moderate severity, while the EPSS score of <1% implies a low likelihood of exploitation in the wild. The vulnerability is not listed in the CISA KEV catalog. An attacker must be able to induce or exploit a Layer‑3 loop on the network path; this is an on‑path attack that does not require special privileges beyond the ability to send traffic to the affected router. Once a loop is established, the absence of hop‑limit decrement causes an infinite forwarding cycle, leading to sustained resource exhaustion.

Generated by OpenCVE AI on August 2, 2026 at 04:09 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Zephyr installation to a version that includes the IPv6 hop‑limit decrement fix, such as any release after the commits 7d8f1afa7345 and 589eadc74efa, which address the explicit‑route and on‑link forwarding paths respectively.
  • If an upgrade is not immediately possible, modify the project configuration to disable IPv6 routing by removing the CONFIG_NET_ROUTE and CONFIG_NET_ROUTING options from the build configuration, thereby preventing the device from acting as an IPv6 forwarder.
  • Implement network monitoring to detect sudden increases in packet forwarding volume or CPU usage indicative of a routing loop, and isolate or quarantine any device that is suspected of forming a forwarding storm.

Generated by OpenCVE AI on August 2, 2026 at 04:09 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 31 Jul 2026 18:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Fri, 31 Jul 2026 17:45:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Fri, 31 Jul 2026 16:15:00 +0000

Type Values Removed Values Added
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).
Title Missing hop-limit decrement on IPv6 forwarding path allows unbounded packet looping (DoS) in Zephyr routers
Weaknesses CWE-835
References
Metrics cvssV3_1

{'score': 5.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L'}


Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-07-31T17:30:15.422Z

Reserved: 2026-06-02T15:26:24.115Z

Link: CVE-2026-10686

cve-icon Vulnrichment

Updated: 2026-07-31T17:30:10.371Z

cve-icon NVD

Status : Analyzed

Published: 2026-07-31T16:16:57.283

Modified: 2026-08-07T18:56:38.893

Link: CVE-2026-10686

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-02T04:15:04Z

Weaknesses
  • CWE-835

    Loop with Unreachable Exit Condition ('Infinite Loop')