EUVD-2026-51557Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
On-path positioning and routing loop induction are non-trivial prerequisites warranting AC:H; PR:N applies as no authentication to the Zephyr device is required.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
7DescriptionNVD
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).
AnalysisAI
IPv6 packet forwarding in Zephyr RTOS versions 1.8.0 through 4.4.1 never decremented the hop limit on routed unicast packets, directly violating RFC 8200's mandatory loop-termination mechanism and enabling indefinite packet circulation in routing loops. Both forwarding 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()) - were affected, with neither performing a hop-limit check nor decrement before calling net_send_data(). An on-path attacker who can induce or exploit a transient L3 routing loop converts it into a permanent forwarding storm, exhausting CPU and link bandwidth on the Zephyr forwarder and adjacent segments; no public exploit or active exploitation has been identified, and SSVC rates exploitation as none with a non-automatable attack.
Technical ContextAI
CWE-835 (Loop with Unreachable Exit Condition) precisely describes this flaw: the IPv6 hop limit field is the RFC 8200-mandated per-hop decrement counter that bounds packet lifetime and signals loop termination to routers. Any compliant IPv6 forwarder must decrement this field at each hop and discard packets when it reaches zero. Zephyr's routing subsystem (subsys/net/ip/route.c, route_ipv6.c) set the forwarding flag and passed packets directly to net_send_data() without touching the hop_limit field in the IPv6 header, creating a condition where CWE-835's unreachable exit applies: no code path decremented the counter, so no exit from forwarding was reachable. The CPE string cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:* covers all Zephyr OS variants across the full affected range. The fix, confirmed in commit 7d8f1afa7345 (explicit-route path) and 589eadc74efa (on-link path), adds hop_limit decrement logic and an expiry check (hop_limit <= 1 returns -ETIMEDOUT) in route_ipv6.c, mirroring correct RFC 8200 router behaviour. Configuration entry points are CONFIG_NET_ROUTE (enabled by default when CONFIG_NET_IPV6_NBR_CACHE is set) and CONFIG_NET_ROUTING for cross-interface forwarding; notably, CONFIG_NET_IPV6_FORWARDING referenced in the fix only exists post-v4.4.0 and is not the relevant config knob for auditing any affected release.
RemediationAI
Upgrade to Zephyr 4.5.0 or later, which incorporates both fix commits: 7d8f1afa7345975b58405d6fba18bb8c3f7cb12a (explicit-route path, hop limit decrement and expiry check) and 589eadc74efa (on-link cross-interface path). The patch details are available at https://github.com/zephyrproject-rtos/zephyr/commit/7d8f1afa7345975b58405d6fba18bb8c3f7cb12a and the vendor advisory at https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4cg6-6jc4-2r6h. If immediate upgrade is not feasible, disabling CONFIG_NET_ROUTE in the Kconfig build configuration eliminates the vulnerable forwarding path entirely; the trade-off is complete loss of IPv6 routing functionality on the device. As a network-level compensating control, configuring adjacent routers to enforce strict hop-limit expiry and drop zero-hop-limit packets prevents looping traffic from propagating beyond the first upstream hop, reducing the blast radius of a forwarding storm without requiring firmware changes to the Zephyr device; however, this relies on correct configuration and capability of upstream infrastructure and does not fix the root cause. For v4.3.1 deployments specifically, only the on-link path (CONFIG_NET_ROUTING) remains unpatched, so disabling CONFIG_NET_ROUTING while retaining CONFIG_NET_ROUTE mitigates the residual exposure with minimal functional impact if cross-interface routing is not required.
Potential off-by-one buffer overflow vulnerability in the Zephyr fuse file system. Rated critical severity (CVSS 10.0),
Possible variant of CVE-2021-3434 in function le_ecred_reconf_req. Rated critical severity (CVSS 9.8), this vulnerabilit
Unchecked user input length in /subsys/net/l2/wifi/wifi_shell.c can cause buffer overflows. Rated critical severity (CVS
Potential buffer overflow vulnerability in the Zephyr CAN bus subsystem. Rated critical severity (CVSS 9.8), this vulner
Integer Underflow in 6LoWPAN IPHC Header Uncompression in Zephyr. Rated critical severity (CVSS 9.8), this vulnerability
Buffer overflow in Zephyr USB DFU DNLOAD. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable
DOS: Incorrect 802154 Frame Validation for Omitted Source / Dest Addresses. Rated critical severity (CVSS 9.8), this vul
zephyr-rtos version 1.12.0 contains a NULL base pointer reference vulnerability in sys_ring_buf_put(), sys_ring_buf_get(
Potential buffer overflow vulnerabilities n the Zephyr Bluetooth subsystem. Rated critical severity (CVSS 9.6), this vul
Buffer overflow in Zephyr RTOS dns_unpack_name() function causing OOB writes. PoC available.
The documentation specifies that the BT_GATT_PERM_READ_LESC and BT_GATT_PERM_WRITE_LESC defines for a Bluetooth characte
Potential buffer overflows in the Bluetooth subsystem due to asserts being disabled in /subsys/bluetooth/host/hci_core.c
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today