← Back to Feed CACHED · 2026-07-01 16:58:10 · CACHE_KEY CVE-2026-14258
CVE-2026-14258 · CWE-835 · Disclosed 2026-07-01

A flaw was found in dhcpcd's IPv6 Neighbor Discovery Router Advertisement processing

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

A rogue box on the same link can wedge your DHCP client, but it has to already be on the wire

CVE-2026-14258 is a CWE-835 infinite loop in dhcpcd's IPv6 Neighbor Discovery Router Advertisement parser. A malformed RA option (classically a zero-length option TLV, or a crafted prefix/RDNSS/DNSSL block) causes the option-walk loop to fail to advance, spinning the daemon until it consumes CPU and stops servicing lease renewal. Affected are dhcpcd builds prior to the July 2026 fix in the NetworkConfiguration/dhcpcd tree — practically speaking, most 9.x and 10.x point releases shipped by Alpine, Gentoo, NetBSD, ChromeOS, and Raspberry Pi OS until distro backports land.

The CVSS breakdown — AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — is honest. Adjacent means Layer-2 reach, not internet-reachable. No confidentiality or integrity impact. Only availability. Vendor MEDIUM (6.5) is defensible; if anything the real-world number is slightly lower because most enterprise access networks either run RA Guard or don't run IPv6 stateless autoconfig at all on managed segments.

"Adjacent-network DoS against a client-side DHCP daemon. Vendor MEDIUM is fair — noise floor, not a fire."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker gains L2 adjacency to a victim segment

The attacker must be on the same broadcast domain as the dhcpcd host — a compromised endpoint, a rogue AP, a plugged-in Pi, or a hostile VM on the same vSwitch port group. IPv6 ND is link-local (ff02::1 multicast, hop-limit 255); it does not route.
Conditions required:
  • Physical or logical L2 presence on the victim VLAN
  • IPv6 enabled on the victim interface
Where this breaks in practice:
  • 802.1X / MACsec on wired ports
  • Client isolation on WLAN
  • Private VLANs / port isolation on switches
  • Segments where IPv6 is administratively disabled
Detection/coverage: NAC (Cisco ISE, Aruba ClearPass, Forescout) flags unknown MACs; nothing CVE-specific here.
STEP 02

Craft a malformed Router Advertisement

Trivial with scapy (ICMPv6ND_RA() + a hand-rolled option with len=0) or thc-ipv6's flood_router26 / fake_router6 modified to emit the pathological TLV. The RA is sent to ff02::1 (all-nodes) or unicast to the victim's link-local address.
Conditions required:
  • Ability to send raw ICMPv6 on the segment
  • Not blocked from sourcing link-local ND traffic
Where this breaks in practice:
  • RA Guard (RFC 6105) on the access switch drops RAs from non-authorized ports
  • IPv6 First-Hop Security policies on Cisco/Juniper/Aruba
Detection/coverage: Suricata/Zeek ICMPv6 anomaly rulesets flag zero-length ND options; most orgs don't run them.
STEP 03

dhcpcd parses the RA and enters the infinite loop

The option-walk in ipv6nd.c fails to advance past the malformed TLV. The daemon pegs a CPU core at 100% and stops processing further ND, DHCPv4 renewals, or address configuration events. There is no memory corruption, no code execution — just a stuck main loop.
Conditions required:
  • Vulnerable dhcpcd version running
  • IPv6 ND processing enabled (default)
Where this breaks in practice:
  • Systems that use systemd-networkd, NetworkManager internal DHCP, ISC dhclient, or udhcpc are not affected
  • Hosts with noipv6 in dhcpcd.conf
Detection/coverage: Any process-CPU monitor (node_exporter, Datadog, CrowdStrike telemetry) shows dhcpcd at 100% — trivially observable post-hoc.
STEP 04

Loss of network configuration state

The host keeps its current lease until expiry, then loses IP configuration when renewal fails. On roaming laptops and IoT/edge devices this manifests as a network drop; on servers with static addressing dhcpcd's death is cosmetic. There is no lateral movement path from this bug.
Conditions required:
  • Attacker sustains the RA flood or victim reboots the daemon into re-infection
Where this breaks in practice:
  • Watchdog / systemd Restart=always brings dhcpcd back, but a persistent attacker just re-sends the RA
Detection/coverage: Endpoint drops off NAC; DHCP lease expiry logs on the server side.
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone observed. No KEV listing, no vendor telemetry, no public campaigns as of 2026-07-02
Public PoCNo dedicated PoC published. Trivially reproducible with scapy — the pattern is analogous to the contiki-ng ND loop GHSA-rr5j-j8m8-fc4f
EPSSNot yet scored (disclosed 2026-07-01). Expect <0.1% — adjacent DoS bugs historically score near-zero
KEV statusNot listed. Availability-only, adjacent-vector bugs are rarely added to KEV
CVSS vectorAV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H → adjacent network, low complexity, no auth, availability-only. Vendor MEDIUM 6.5 — accurate
CWECWE-835 — Loop with Unreachable Exit Condition ('Infinite Loop')
Affected versionsdhcpcd releases prior to the July 2026 fix commit in NetworkConfiguration/dhcpcd. Alpine, Gentoo, NetBSD, ChromeOS base, Raspberry Pi OS ship dhcpcd by default; most other mainstream distros do not
Fixed versionsUpstream patch merged 2026-07 — check distro backports (Alpine apk info dhcpcd, Gentoo GLSA, Raspberry Pi OS security update)
Exposure populationZero internet-reachable exposure by design (adjacent vector). Shodan/Censys not meaningful for this CVE. Internal exposure = every LAN-attached host running vulnerable dhcpcd with IPv6 enabled
ReporterReported upstream to the NetworkConfiguration/dhcpcd maintainer (Roy Marples). No named external researcher in the initial advisory
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.3/10)

The single decisive factor is vector = Adjacent (AV:A) with availability-only impact and no code execution path — the attacker must already sit on the victim's L2 segment, and success buys them a stuck DHCP client, not a shell. Even in the worst deployment role (edge router / IoT gateway running dhcpcd), the blast radius is loss of dynamic address renewal, not fleet compromise.

HIGH impact ceiling (availability-only, no RCE path)
HIGH adjacency requirement — link-local ND cannot be routed
MEDIUM installed-base breadth pending distro triage

Why this verdict

  • Vector is Adjacent, not Network. IPv6 ND is link-local by protocol design (hop-limit 255 check). No internet-facing exposure is possible. This alone caps severity below HIGH.
  • Impact is availability-only. C:N/I:N/A:H — no memory corruption, no code execution, no data exposure. The worst outcome is dhcpcd pegging a core and losing lease renewal.
  • Friction: RA Guard is a widely deployed control on enterprise access switches (Cisco, Aruba, Juniper all ship it). Where deployed, the malicious RA never reaches the victim.
  • Role multiplier — workstation/laptop role: chain succeeds → user loses network on lease expiry, self-heals on daemon restart. Blast radius = single host, transient.
  • Role multiplier — server role: most Linux servers do not run dhcpcd (systemd-networkd, NetworkManager, or static config dominate). Where dhcpcd is present (Alpine containers, Raspberry Pi appliances), servers usually have static IPv6 or IPv6 disabled. Blast radius = single host availability.
  • Role multiplier — edge/IoT gateway role (highest realistic): ChromeOS, OpenWrt-adjacent, Raspberry Pi appliances. Chain succeeds → gateway loses upstream config. Blast radius still bounded to the appliance itself; no pivot, no identity, no data plane compromise. This does not trip the HIGH floor because the outcome is not fleet-scale or identity-scale.
  • No KEV, no known exploitation, EPSS effectively zero — no urgency multiplier.

Why not higher?

HIGH would require either a code execution path, a fleet-scale blast radius, or active exploitation. This bug has none: it is a local CPU spin on a client-side daemon, reachable only from the same L2 segment, with no lateral movement primitive. Even a domain controller running dhcpcd (vanishingly rare) would only lose its dynamic IPv6 lease — AD services continue on the existing address.

Why not lower?

LOW would ignore the fact that the attacker requirements are trivial once on-segment (any guest Wi-Fi, any rogue device in a conference room, any compromised endpoint on the user VLAN), and that the outage can be sustained cheaply. On Alpine/ChromeOS/Raspberry Pi fleets the affected population is real and non-trivial, so this is not backlog hygiene — it earns a MEDIUM patch cycle.

05 · Compensating Control

What to do — in priority order.

  1. Enable RA Guard on access switches — RFC 6105 first-hop security drops Router Advertisements sourced from non-authorized ports. On Cisco: ipv6 nd raguard policy and apply to access interfaces. On Aruba/Juniper equivalent. This neutralizes the delivery vector for every RA-based bug, not just this one. Deploy per noisgate mitigation SLA — no formal MEDIUM SLA, treat as standard hardening within the 365-day remediation window.
  2. Inventory dhcpcd installs and disable IPv6 ND where not needed — Add noipv6rs or noipv6 to /etc/dhcpcd.conf on hosts that only need IPv4 leasing. Kills the parser exposure entirely.
  3. Configure dhcpcd under a supervisor with rate-limited restartsystemd unit with Restart=on-failure and StartLimitBurst=3 — combined with a watchdog that kills the daemon when CPU >95% for >60s, this bounds the outage window and forces the attacker to sustain the flood.
  4. Switch to systemd-networkd or NetworkManager on servers — Where dhcpcd is not architecturally required (most non-Alpine/non-Pi installs), removing the package removes the bug. Track via package inventory queries.
What doesn't work
  • Perimeter firewalls / WAF — the attack is L2 link-local, it never touches your edge
  • IPS signatures on north-south traffic — same reason; RAs stay on the local segment
  • EDR memory protection — there is no shellcode or exploit primitive to catch; the daemon just spins
  • MFA / identity controls — irrelevant, no authentication is involved
  • Disabling IPv6 at the OS level after dhcpcd is already parsing — dhcpcd must be reconfigured to not process ND; sysctl net.ipv6.conf.all.disable_ipv6=1 alone may not stop the daemon from parsing RAs on interfaces it has claimed
06 · Verification

Crowdsourced verification payload.

Run on each Linux/BSD target host as root or via your config-management runner (Ansible/Salt). Example: sudo ./check-cve-2026-14258.sh. Compares installed dhcpcd version against the fixed baseline and reports VULNERABLE / PATCHED / UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# noisgate check: CVE-2026-14258 — dhcpcd IPv6 ND RA infinite loop (CWE-835)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN/NOT_INSTALLED
set -u

FIXED_VERSION="10.2.4"  # placeholder — replace with the exact fixed release tag from your distro

if ! command -v dhcpcd >/dev/null 2>&1; then
  echo "UNKNOWN: dhcpcd not present on this host"
  exit 2
fi

RAW=$(dhcpcd --version 2>/dev/null | head -n1 || true)
VER=$(echo "$RAW" | grep -oE '[0-9]+(\.[0-9]+){1,3}' | head -n1)

if [ -z "$VER" ]; then
  echo "UNKNOWN: could not parse dhcpcd version from: $RAW"
  exit 2
fi

# semver-ish compare
vercmp() {
  # returns 0 if $1 >= $2
  [ "$1" = "$2" ] && return 0
  printf '%s\n%s\n' "$2" "$1" | sort -V -C && return 0 || return 1
}

# Check if IPv6 ND is actually processed (mitigating config)
ND_DISABLED="no"
if [ -f /etc/dhcpcd.conf ] && grep -qE '^\s*(noipv6rs|noipv6)\b' /etc/dhcpcd.conf; then
  ND_DISABLED="yes"
fi

if vercmp "$VER" "$FIXED_VERSION"; then
  echo "PATCHED: dhcpcd $VER >= $FIXED_VERSION"
  exit 0
else
  if [ "$ND_DISABLED" = "yes" ]; then
    echo "PATCHED (mitigated): dhcpcd $VER is vulnerable but IPv6 RS/RA processing is disabled in dhcpcd.conf"
    exit 0
  fi
  echo "VULNERABLE: dhcpcd $VER < $FIXED_VERSION and IPv6 ND processing is enabled"
  exit 1
fi
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: query your CMDB / package inventory for dhcpcd — if you are a mainstream RHEL/Ubuntu/Debian/SUSE shop, this is a ten-minute nothing. If you run Alpine containers, ChromeOS fleets, Raspberry Pi appliances, or NetBSD, this is a real (but not urgent) patch cycle. Under the noisgate mitigation SLA for MEDIUM there is no formal mitigation deadline — go straight to the noisgate remediation SLA of ≤ 365 days and roll the fix in with your next quarterly patch train. In parallel, verify RA Guard is enabled on access switches (this pays dividends across the entire IPv6 ND bug class). Do not page anyone. Do not open a Sev-1 ticket.

Sources

  1. NetworkConfiguration/dhcpcd upstream
  2. Contiki-NG IPv6 ND infinite loop advisory (analogous bug class)
  3. RFC 6105 — IPv6 RA Guard
  4. RFC 3756 — IPv6 ND Trust Models and Threats
  5. IETF: Security Assessment of ND for IPv6
  6. F5 K9528 — NDP vulnerability reference
  7. MITRE CWE-835 — Loop with Unreachable Exit Condition
  8. Cisco IPv6 ND crafted packet DoS advisory (bug-class precedent)
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.