CVE-2026-10686
MediumCVSS 5.8Exploitation Probability (EPSS)
Low risk22th percentile - higher than 22% of all known CVEs
Summary
In Zephyr OS, a vulnerability exists in the IPv6 forwarding path where the hop limit is not decremented. This allows an IPv6 router to forward packets indefinitely, leading to network congestion and resource exhaustion.
Risk Assessment
An attacker can exploit this vulnerability to cause a permanent routing storm, resulting in denial of service (DoS) on the device and adjacent links.
Recommendation
Immediately update Zephyr OS to a version containing the fixes (commits 7d8f1afa7345 and 589eadc74efa) or apply the relevant security patches.
Other vulnerabilities in Zephyr
See all- CVE-2026-10772Unknown
This CVE has been rejected as a duplicate. The described vulnerability involved incorrect permission checking in the Bluetooth GATT notify/indicate paths in the Zephyr stack, but was already reported as CVE-2026-2411.
- CVE-2026-10676Unknown
CVE-2026-10676 has been withdrawn as analysis determined that the reported defect is not reachable in any released version of Zephyr. In every supported release, the affected value is corrected before use.
- CVE-2026-5067Critical
Zephyr OS has a memory corruption vulnerability in the HTTP server WebSocket upgrade path. An unauthenticated remote attacker can trigger it by sending a crafted Sec-WebSocket-Key header. The bounded copy does not guarantee NUL termination, leading to out-of-bounds read/write on stack.
- CVE-2026-13735Low
Zephyr's WireGuard implementation mishandled keepalive packets. A type-4 message with a 16-byte payload (empty plaintext plus Poly1305 tag) was accepted without tag verification because wg_process_data_message() returned early before calling wg_decrypt_packet(). An attacker could send a forged keepalive without knowing the session key.
- CVE-2026-13734Medium
Vulnerability in Zephyr's WireGuard VPN: wg_process_data_message() validated the anti-replay counter too late, after committing peer-state changes (address update, timers, key rotation). An attacker can re-inject a captured packet, leading to endpoint hijacking and session disruption.
- CVE-2026-13212High
The Zephyr virtio driver does not validate the descriptor-chain head id written by the virtio device into the used ring. A malicious virtio backend can supply an out-of-range id, causing an out-of-bounds read and invocation of an attacker-controlled function pointer in the guest's interrupt context. This enables control-flow hijacking or a reliable crash.
- CVE-2026-12634Medium
A vulnerability in the NVS backend of the Zephyr settings subsystem (settings_nvs.c) causes an out-of-bounds stack write. The nvs_read() function returns the full entry length, which can exceed the buffer size, and the code uses this value as an index for writing a NUL character, leading to a write past the buffer (CWE-787).
- CVE-2026-12632Medium
A vulnerability in Zephyr RTOS's PTP receive handler allows a remote attacker to trigger an out-of-bounds read by sending a crafted PTP packet with an invalid message type (0xE or 0xF). The lack of an upper-bound check on the msg_size[] array index leads to reading beyond the array and subsequent memory operations, potentially causing a crash or limited memory corruption.
- CVE-2026-12630Medium
Zephyr's 6LoWPAN IPHC uncompression code contains an out-of-bounds read in get_ihpc_inlined_size() (subsys/net/ip/6lo.c). The destination inline size is looked up in da_inline_size_table (13 entries) using an index built from the M, DAC and DAM bits of the IPHC dispatch word; reserved combinations 13, 14 and 15 are not bounds-checked and read past the end of the table.
- CVE-2026-12366High
A use-after-free vulnerability exists in Zephyr's dynamic kernel-object disposal path. The unref_check() function frees object storage when the reference count reaches zero, but for timers (K_OBJ_TIMER) it does not cancel the active timeout, leaving a dangling node in the global timeout queue. When the timer expires, the kernel invokes the expiration handler on freed memory, causing a write to freed heap.
Original NVD description (English source)
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).

