CVE Tools

CVE-2026-16515

ICMPv6 error messages sent for multicast-destined packets and non-unique source addresses enable network amplification in Zephyr's IPv6 stack

Published: Sep 18, 2026Updated: Sep 18, 2026 Sources: CVE List NVDCWE-406

Description

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.

No summary for this CVE yet.

CVSS Vector Breakdown

AV:AAC:LPR:NUI:NS:CC:NI:NA:L
Exploitability
AV:AAttack Vector
Adjacent
AC:LAttack Complexity
Low
PR:NPrivileges Required
None
UI:NUser Interaction
None
Scope
S:CScope
Changed
Impact
C:NConfidentiality
None
I:NIntegrity
None
A:LAvailability
Low

Weaknesses

Affected Products

Exploitability

No known exploits, KEV entries, or remediation guidance available for this vulnerability yet.

References

Unlock Complete Vulnerability Intelligence

Get the full picture for CVE-2026-16515 and every CVE in our database. Create a free account — no credit card required.

Create Free Account
Plain-language analysis
Impact assessment and exploitation scenario in plain English
Attack graph visualization
Interactive attack path and kill chain mapping
Exploit details & PoC links
ExploitDB, Metasploit, GitHub PoCs with direct links
Nuclei scanner templates
Ready-to-use vulnerability scanner templates
Full remediation guide
Patch instructions, workarounds, and compliance impact
Interactive AI chat
Ask questions about this vulnerability in natural language
Related vulnerabilities
Semantically similar CVEs and attack patterns
REST API & MCP access
Integrate vulnerability data into your workflows

We use analytics cookies to see which pages and articles actually help people. Decline and none of them run — the site works the same. What we store