OpenWrt odhcpd DHCPv6 IA Reply Serialization Stack Buffer Overflow

CVE-2026-53921 is a stack-based buffer overflow (CWE-121) in odhcpd, the default DHCPv6/RA/NDP daemon shipped with every OpenWrt installation. Two independent overflow sites exist in the DHCPv6 IA reply serialization path: one in build_ia() at dhcpv6-ia.c:594 where a 6-byte status sub-option writes past a 16-byte guard, and a second at dhcpv6-ia.c:1246 where a 36-byte RECONF_ACCEPT authentication record is written unconditionally without bounds checking. Both overflow a fixed 512-byte stack buffer (pdbuf). An unauthenticated attacker on the LAN sends a crafted DHCPv6 REQUEST to UDP/547 — no credentials, no user interaction. Because odhcpd runs as root and OpenWrt's embedded MIPS/ARM targets typically ship without stack canaries or ASLR, the path from stack smash to arbitrary code execution is essentially unguarded. All odhcpd versions through master commit e432dd6 are vulnerable. Patched in OpenWrt 24.10.8 and 25.12.5.

The CNA (OpenWrt/GitHub) assigned CVSS 9.8 — and for the raw technical mechanics, that score is fair. AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H accurately describes the attack surface *within the reachable network*. The only friction is that the DHCPv6 server listens on the LAN interface by design, not the WAN — so an internet-remote attacker cannot reach it directly. In practice, though, this friction is thinner than it looks: any compromised endpoint, rogue IoT device, or guest-WiFi client on the same segment can fire the exploit. For a router — the single device that sees all traffic and controls all routing — the blast radius of root compromise is network-wide: MitM, DNS hijack, credential harvesting, and a silent lateral-movement pivot. We assess this at CRITICAL 9.0, slightly below the raw CVSS to account for LAN-only reachability and the absence of confirmed in-the-wild exploitation, but we hold the CRITICAL floor because OpenWrt *is* the network edge appliance.

Why this verdict

• Unauthenticated, zero-click attack surface. The trigger is a single DHCPv6 REQUEST packet to UDP/547 — no credentials, no user interaction, no prior session. Any device on the LAN segment can fire it. This is the lowest possible friction for a network-reachable vulnerability.
• Exploit mitigations are absent on the target platform. OpenWrt's embedded MIPS and ARM targets typically ship without stack canaries (SSP) and without ASLR. The advisory explicitly calls this out. A stack buffer overflow on these platforms is essentially a guaranteed code execution primitive, not a probabilistic crash.
• Public PoC lowers the weaponization bar. Two complete Python PoC scripts (~120 lines each) are included directly in the GitHub Security Advisory. While they are ASan test harnesses rather than full exploit chains, they provide the exact packet structures, IA option counts, and triggering sequences. Converting to a weaponized exploit requires only shellcode/ROP payload development — trivial given the no-ASLR/no-canary environment.
• Role multiplier: canonical network edge appliance — chain ends in network-wide compromise. OpenWrt devices are routers, gateways, and firewalls by definition. Root on the router means: (a) full traffic interception and modification (MitM on all LAN↔WAN flows), (b) DNS poisoning affecting every client, (c) firewall rule manipulation opening the network to external attack, (d) silent lateral-movement pivot to all LAN hosts, (e) persistent backdoor surviving service restarts. This is fleet-scale impact for every network segment behind the compromised device. The blast radius is not 'one host' — it is 'every host on that network segment plus the WAN uplink.' Because ≥10% (in fact 100%) of OpenWrt installations occupy the high-value network-edge role, the verdict floor is CRITICAL per noisgate methodology.
• LAN-only reachability is real friction but does not break the CRITICAL floor. The DHCPv6 server binds to the LAN interface, not WAN. An internet-remote attacker cannot reach it directly. However, this requires only that the attacker have *any* presence on the LAN — a compromised endpoint, a rogue IoT device, a guest WiFi client. In enterprise branch-office and retail deployments, this is a realistic post-initial-access position. Per noisgate rules, a generic 'requires internal access' statement is not sufficient to break below the CRITICAL floor for a canonical network-edge component.

Why not higher?

The CNA score is 9.8; we assess at 9.0. The 0.8-point reduction reflects that DHCPv6 is LAN-facing only (not internet-reachable), exploitation requires IPv6 and DHCPv6 to be active on the target segment, and there is no confirmed in-the-wild exploitation or KEV listing yet. The public PoCs are ASan instrumentation harnesses rather than weaponized remote shells, adding a small (but surmountable) gap to operational exploitation.

Why not lower?

Downgrading to HIGH would require evidence that the network-edge blast radius is contained — but it is not. Root on the router IS the network. The LAN-only requirement is the sole friction point, and it is a single hop from any compromised endpoint. The absence of exploit mitigations (no ASLR, no canaries) on target hardware makes exploitation reliability exceptionally high. Two independent overflow paths mean a defender cannot partially patch. Public PoC code removes the discovery barrier. For any enterprise running OpenWrt in branch offices, retail, or OT segments, this is a CRITICAL-class threat.

1. Disable DHCPv6 server mode on all OpenWrt devices immediately — If your network segments do not require DHCPv6 (many enterprise LANs are IPv4-only or use SLAAC without stateful DHCPv6), set option dhcpv6 disabled in /etc/config/dhcp for each interface and restart odhcpd. This eliminates the attack surface entirely. Deploy within 3 days per noisgate mitigation SLA for CRITICAL.
2. Restrict DHCPv6 to trusted VLANs via firewall rules — If DHCPv6 cannot be disabled, add iptables/nftables rules on the OpenWrt device to drop DHCPv6 traffic (UDP/547) from untrusted VLANs, guest networks, and IoT segments. Only allow DHCPv6 from managed infrastructure VLANs. This limits the attack surface to segments where all clients are enterprise-managed.
3. Enable stack smashing protector (SSP) in custom builds — If you build OpenWrt from source, enable -fstack-protector-strong in the toolchain configuration. This adds stack canaries that will terminate odhcpd on overflow rather than allowing code execution. Note: this requires a firmware rebuild and reflash — it is a build-time mitigation, not a runtime config change.
4. Monitor syslog for odhcpd crashes — Configure syslog forwarding from all OpenWrt devices to your SIEM. Alert on odhcpd segfault or unexpected restart events, which would indicate exploitation attempts. This is detection, not prevention, but provides early warning.
5. Upgrade to OpenWrt 24.10.8 or 25.12.5 — The definitive fix. Plan firmware upgrades within the 90-day noisgate remediation SLA for CRITICAL. Prioritize devices on segments with untrusted clients (guest WiFi, IoT, retail floor).

Run this script on each OpenWrt device via SSH (as root). It checks the installed odhcpd package version and the OpenWrt release version against known-patched releases. Invoke with: ssh root@<router-ip> 'sh -s' < check_cve_2026_53921.sh

#!/bin/sh
# check_cve_2026_53921.sh
# Checks whether the running OpenWrt device is vulnerable to CVE-2026-53921
# (odhcpd DHCPv6 stack buffer overflow)
# Run as root on the OpenWrt device.
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

RESULT="UNKNOWN"

# Check if odhcpd is installed
if ! opkg list-installed 2>/dev/null | grep -q '^odhcpd'; then
  echo "[*] odhcpd is not installed on this device."
  echo "PATCHED (not affected — odhcpd not present)"
  exit 0
fi

# Check if DHCPv6 server is active
DHCPV6_ACTIVE=$(uci show dhcp 2>/dev/null | grep "dhcpv6='server'" | head -1)
if [ -z "$DHCPV6_ACTIVE" ]; then
  echo "[*] DHCPv6 server mode is not enabled (attack surface not exposed)."
  echo "[*] Still checking version for completeness..."
fi

# Get OpenWrt release version
if [ -f /etc/openwrt_release ]; then
  . /etc/openwrt_release
  RELEASE="$DISTRIB_RELEASE"
  echo "[*] OpenWrt release: $RELEASE"
else
  echo "[!] Cannot determine OpenWrt release version."
  echo "UNKNOWN"
  exit 2
fi

# Parse major.minor.patch
MAJOR=$(echo "$RELEASE" | cut -d. -f1)
MINOR=$(echo "$RELEASE" | cut -d. -f2)
PATCH=$(echo "$RELEASE" | cut -d. -f3 | cut -d- -f1)

# Vulnerable ranges:
# 24.10.0 - 24.10.7  (fixed in 24.10.8)
# 25.12.0 - 25.12.4  (fixed in 25.12.5)
# Anything older than 24.10 is also vulnerable if odhcpd is present

if [ "$MAJOR" -eq 24 ] && [ "$MINOR" -eq 10 ]; then
  if [ "$PATCH" -ge 8 ]; then
    RESULT="PATCHED"
  else
    RESULT="VULNERABLE"
  fi
elif [ "$MAJOR" -eq 25 ] && [ "$MINOR" -eq 12 ]; then
  if [ "$PATCH" -ge 5 ]; then
    RESULT="PATCHED"
  else
    RESULT="VULNERABLE"
  fi
elif [ "$MAJOR" -gt 25 ] || ([ "$MAJOR" -eq 25 ] && [ "$MINOR" -gt 12 ]); then
  RESULT="PATCHED"
elif [ "$MAJOR" -lt 24 ] || ([ "$MAJOR" -eq 24 ] && [ "$MINOR" -lt 10 ]); then
  # Older branches — likely vulnerable if odhcpd has the affected functions
  RESULT="VULNERABLE"
else
  RESULT="UNKNOWN"
fi

if [ "$RESULT" = "VULNERABLE" ]; then
  echo "[!] CVE-2026-53921: VULNERABLE"
  echo "[!] OpenWrt $RELEASE contains a vulnerable odhcpd version."
  echo "[!] Upgrade to 24.10.8 or 25.12.5 immediately."
  if [ -n "$DHCPV6_ACTIVE" ]; then
    echo "[!] WARNING: DHCPv6 server mode is ACTIVE — attack surface is exposed."
  fi
  echo "VULNERABLE"
  exit 1
elif [ "$RESULT" = "PATCHED" ]; then
  echo "[+] CVE-2026-53921: PATCHED"
  echo "[+] OpenWrt $RELEASE includes the fix."
  echo "PATCHED"
  exit 0
else
  echo "[?] CVE-2026-53921: UNKNOWN"
  echo "[?] Could not determine patch status for OpenWrt $RELEASE."
  echo "UNKNOWN"
  exit 2
fi

Sources

1. GitHub Security Advisory GHSA-7fwx-hhrg-3496
2. The Hacker News — Critical OpenWrt DHCPv6 Flaw Coverage
3. Field Effect — Critical OpenWrt DHCPv6 Flaw Analysis
4. SC Media — OpenWrt Security Updates
5. heise online — OpenWrt Updates Close Critical Vulnerabilities
6. Forescout — Analyzing Active Exploitation of OpenWRT LuCI
7. OpenWrt odhcpd GitHub Repository