Skip to main content
VulnerabilityPublished Updated

CVE-2026-7656: zephyrproject zephyr · Input-validation

Affects zephyrproject zephyrSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 8.1 High : upgrade to 4.6.0 soon.

Data as of 10 Nov 2026, 23:24 UTC

CVSS 3.1 base score
8.1High
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (zephyr)CVSS 3.18.1
EPSS
0.3% chance of exploitation in 30 days – higher than 26% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 4.6.0
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 29 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 11 Nov 2026.

What to do

Upgrade zephyrproject zephyr to 4.6.0.

Affected software

ProductAffectedFixed in
zephyrprojectzephyrAffected
  • >=1.14.0 <4.6.0
Fixed in
  • 4.6.0
GitHubzephyrpkg:github/zephyrOther threatsAffected
  • >=1.14.0 <4.6.0
Fixed in
  • 4.6.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

The vulnerability is fixed by correcting the boolean logic in the IPv6 ND handlers to ensure all validity checks are enforced and packets failing any check are dropped. If you cannot patch yet, network administrators should be aware of the risk of forged ND messages and consider network-level protections against rogue IPv6 ND traffic where feasible.

Description

The IPv6 Neighbor Discovery handlers in subsys/net/ip/ipv6_nbr.c (handle_ra_input, handle_ns_input, handle_na_input) used an incorrect boolean expression that combined the RFC 4861 validity checks with the ICMPv6 code check using the wrong operator precedence: the form was ((length/hop/source/target checks) && (icmp_hdr->code != 0)). Because every legitimate ND message carries ICMPv6 code 0, an attacker setting code == 0 (the normal value) caused the entire predicate to evaluate false, so the packet was never dropped and all of the other checks were silently skipped. The bypassed checks include the mandatory Hop Limit == 255 verification (which proves an ND packet originated on-link and was not forwarded) and, for Router Advertisements, the requirement that the source be a link-local address, as well as multicast-target sanity checks. As a result, an adjacent on-link attacker — and, because the Hop-Limit-255 guard is bypassed, potentially a remote/off-link attacker whose packets would otherwise be rejected — can have forged Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages accepted. A forged RA lets the attacker reconfigure the victim's default router, on-link prefixes (SLAAC), MTU, reachable/retransmit timers, and (with CONFIG_NET_IPV6_RA_RDNSS) DNS servers, while forged NS/NA enable neighbor-cache poisoning, enabling man-in-the-middle, traffic redirection, and denial of service. The flaw is an input-validation/authentication weakness rather than a memory-safety issue: the underlying packet-parsing primitives (net_pkt_get_data, net_pkt_read, net_pkt_skip) are independently bounds-safe and the validated length is the true buffer length, so skipping the length check causes no out-of-bounds access. The defect has existed since the logic was introduced in 2018 and shipped in all releases through v4.4.0; it is fixed by splitting the condition so any failing check drops the packet.

References

Community reviews

Loading reviews…