CVE-2026-10686
Full vulnerability record from the local CVENow database.
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).
View original CVE JSON
{
"id": "CVE-2026-10686",
"sourceIdentifier": "[email protected]",
"published": "2026-07-31T16:16:57.283",
"lastModified": "2026-10-23T23:10:00.157",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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.\n\nPer 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.\n\nAffected 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.\n\nIPv4 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.\n\nAffected 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)."
},
{
"lang": "es",
"value": "La ruta de reenvío IPv6 de Zephyr reenvió paquetes unicast enrutados sin nunca decrementar el límite de saltos IPv6. Ambas ramas de enrutamiento de ipv6_route_packet() (subsys/net/ip) se vieron afectadas: la ruta de enrutamiento explícito (net_route_packet()) y la ruta entre interfaces en el mismo enlace (net_route_packet_if()). Cada una estableció el indicador de reenvío de paquetes y llamó a net_send_data() con el límite de saltos intacto y sin verificación de caducidad.\n\nSegún la RFC 8200, el decremento del límite de saltos es el mecanismo que limita la vida útil de los paquetes y termina los bucles de enrutamiento; sin él, un dispositivo que actúa como un router IPv6 retransmite paquetes en bucle indefinidamente. Un atacante en la ruta que puede inducir o explotar un bucle L3 transitorio lo convierte en una tormenta de reenvío permanente, causando el agotamiento de recursos de CPU/ancho de banda (DoS de disponibilidad) en el reenviador y los enlaces adyacentes; el descubrimiento de rutas y los diagnósticos de bucles que dependen de la caducidad del límite de saltos también se ven frustrados.\n\nConfiguraciones afectadas. En cada versión afectada, se accede a la ruta de reenvío a través de CONFIG_NET_ROUTE (habilitado por defecto cuando CONFIG_NET_IPV6_NBR_CACHE está configurado), junto con CONFIG_NET_ROUTING para el enrutamiento entre interfaces. Tenga en cuenta que CONFIG_NET_IPV6_FORWARDING y CONFIG_NET_IPV4_FORWARDING - que aparecen en la corrección y en las notas de evidencia de este aviso - se introdujeron después de la v4.4.0, cuando las opciones de enrutamiento se dividieron y renombraron; no existen en ninguna versión afectada. Al auditar una configuración de v4.4.1 o anterior, busque CONFIG_NET_ROUTE y CONFIG_NET_ROUTING.\n\nIPv4 no se ve afectado en ninguna versión. La ruta de reenvío IPv4 (net_route_ipv4_packet() en route_ipv4.c) se añadió después de la v4.4.0 y nunca se ha enviado en una versión. Su decremento de TTL y el recálculo de la suma de verificación del encabezado IPv4 llegaron a la rama principal como parte de la misma corrección, por lo que las notas de evidencia a continuación lo discuten, pero ninguna versión publicada es accesible por medio de IPv4.\n\nLas versiones afectadas son de la v1.8.0 a la v4.4.1: la v1.8.0 introdujo net_route_packet() y la v2.2.0 añadió net_route_packet_if(), y ninguna de ellas decrementó el límite de saltos. La v4.3.1 incluye la corrección de la ruta explícita pero no la del enlace, por lo que también se ve afectada. Corregido en la rama principal por 7d8f1afa7345 (ruta de enrutamiento explícito) y 589eadc74efa (ruta en el enlace)."
}
],
"affected": [
{
"source": "[email protected]",
"affectedData": [
{
"vendor": "zephyrproject",
"product": "zephyr",
"defaultStatus": "unaffected",
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"packageName": "zephyr",
"programFiles": [
"subsys/net/ip/ipv4.c",
"subsys/net/ip/ipv6.c",
"subsys/net/ip/route.c",
"subsys/net/ip/route_ipv4.c",
"subsys/net/ip/route_ipv6.c"
],
"versions": [
{
"version": "1.8.0",
"lessThan": "4.3.1",
"versionType": "semver",
"status": "affected"
},
{
"version": "4.4.0",
"lessThan": "4.4.2",
"versionType": "semver",
"status": "affected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "[email protected]",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
"baseScore": 5.8,
"baseSeverity": "MEDIUM",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "CHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "LOW"
},
"exploitabilityScore": 3.9,
"impactScore": 1.4
},
{
"source": "[email protected]",
"type": "Primary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2026-07-31T17:24:49.110523Z",
"id": "CVE-2026-10686",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"version": "2.0.3"
}
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-835"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:*",
"versionStartIncluding": "1.8.0",
"versionEndExcluding": "4.5.0",
"matchCriteriaId": "30B0A375-EBBE-4F4C-97EF-F377509D7F9A"
}
]
}
]
}
],
"references": [
{
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/7d8f1afa7345975b58405d6fba18bb8c3f7cb12a",
"source": "[email protected]",
"tags": [
"Patch"
]
},
{
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4cg6-6jc4-2r6h",
"source": "[email protected]",
"tags": [
"Exploit",
"Patch",
"Vendor Advisory"
]
}
]
}