CVE-2026-16515

What it is

net_icmpv6_send_error() in subsys/net/ip/icmpv6.c implemented only one of the three RFC 4443 section 2.4 suppression rules (do not answer an ICMPv6 error with an ICMPv6 error). It did not check whether the triggering packet's source address identifies a single node (rule e.6) or whether the packet was sent to a multicast destination (rule e.3, whose only exceptions are Packet Too Big and Parameter Problem Code 2). Of the five call sites, only the port-unreachable path in subsys/net/ip/connection.c carried an equivalent guard of its own; the extension-header, unknown-next-header and fragmentation paths in subsys/net/ip/ipv6.c and subsys/net/ip/ipv6_fragment.c had none. An unauthenticated attacker with access to the same link can exploit this in two ways. Sending a single IPv6 packet to the link-local all-nodes group ff02::1 carrying an unrecognized next-header value, with the source address spoofed to a chosen victim, causes every Zephyr node on the link to emit an ICMPv6 Parameter Problem message to that victim — a reflector with an amplification factor equal to the number of nodes. Alternatively, sending a unicast packet whose source address is a multicast address causes the node to transmit its ICMPv6 error to that multicast address, turning one unicast packet into a link-flooded multicast frame. Packets addressed to ff02::1 are accepted unconditionally by ipv6_input(), and no check rejects a multicast source address, so no special configuration is required. The impact is degraded availability of the shared link and of the reflection victim, together with the ability for the attacker to hide its own address behind the responding nodes. The effect is amplified on constrained mesh links such as 802.15.4/Thread, where link-local multicast is flooded hop by hop. There is no memory-safety consequence: the error packet itself is well formed, it is simply emitted in cases where the protocol forbids it. The fix adds both suppression checks at the single choke point in net_icmpv6_send_error(), before any reply packet is allocated, preserving the RFC-mandated exceptions for NET_ICMPV6_PACKET_TOO_BIG and Parameter Problem Code 2. Note that the IPv4 counterpart net_icmpv4_send_error() in subsys/net/ip/icmpv4.c still checks only for a broadcast destination and retains an equivalent gap for multicast destinations and non-unique sources.

At a glance

Exploitability

Can be exploited from the same network segment without logging in. Limited direct impact.

Exploit odds

0.2% chance of exploitation in the next 30 days (EPSS).

Fix

A patch, advisory or fixed version is referenced. Upgrade or apply it.

Timeline

1. 2026-09-18 15:17 UTC PublishedDisclosed publicly on CVE.org and NVD
2. 2026-11-04 05:18 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: 0.2% in the next 30 days (EPSS).
• Severity: 4.7 MEDIUM (CVSS).
• Fix: a patch or advisory is linked.

Details

Published

2026-09-18 15:17 UTC

Last modified

2026-11-04 05:18 UTC

Exploit probability

0.2% · EPSS, next 30 days

Weakness

CWE-406

Record status

Awaiting Analysis

Attack profile CVSS 3.1 · 4.7

Attack vector

Adjacent network

Complexity

Low

Privileges needed

None

User interaction

None

Scope

Changed

Confidentiality

None

Integrity

None

Availability

Low

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-16515.md and follow it. Check whether this project is affected by CVE-2026-16515. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge