This is a fire alarm going off in a house you don't live in
CVE-2026-86296 is a stack-based buffer overflow in the DHCP daemon (udhcpcd) on D-Link DIR-822A routers running firmware version A_101. The vulnerable strcpy call in udhcpcd/serverpacket.c copies attacker-controlled data from DHCP option 125 (TR-111 vendor-specific subfields) into a fixed 256-byte stack buffer without bounds checking. An unauthenticated attacker on the same LAN segment can send a crafted DHCP packet to corrupt the stack, crash the daemon, and — under unconfirmed conditions — potentially achieve code execution as root. The affected device is a consumer-grade, non-US, SOHO Wi-Fi router that D-Link has declared End of Life. No firmware patch exists or is expected.
The vendor CVSS of 10.0 is a textbook example of a score that is technically defensible in a vacuum but wildly misleading for enterprise defenders. The vector uses AV:N (Network), but DHCP is a Layer 2 broadcast-domain protocol — you must be on the same local segment to deliver the malicious packet. The correct attack vector is AV:A (Adjacent Network). Even correcting to AV:A still yields a 9.6 base score, but the real-world severity plummets further: the DIR-822A is a $30 consumer router that has no business being in a managed enterprise fleet, reliable RCE has not been demonstrated (only DoS is confirmed), and the device is EOL with zero prospect of a vendor fix. For a team managing 10,000 hosts, this CVE is a housekeeping item — find and replace any strays — not a war-room event.
4 steps from start to impact.
Attacker gains LAN adjacency
- Physical or wireless access to the LAN segment served by the DIR-822A
- Or prior compromise of a host on the same VLAN/broadcast domain
- Enterprise networks rarely deploy consumer SOHO routers as managed infrastructure
- 802.1X / NAC would block unauthorized devices from joining the LAN
- Wireless requires knowing the PSK or passing WPA2/3 authentication
Craft malicious DHCP packet with option 125 payload
strcpy into a fixed stack buffer.- Knowledge of the vulnerability (public PoC available)
- Ability to send raw DHCP packets on the LAN
- DHCP snooping on enterprise switches would drop untrusted DHCP traffic
- VLAN segmentation isolates the blast radius to the local segment
Trigger stack buffer overflow in udhcpcd
strcpy overflows the 256-byte stack buffer. This corrupts the stack frame, overwriting the return address and potentially other control data. The confirmed outcome is a daemon crash (DoS). Under specific memory layout conditions, the attacker may achieve control of the instruction pointer.- DIR-822A running firmware A_101 with vulnerable udhcpcd
- No ASLR/stack canaries on this MIPS-based consumer firmware (typical for this device class)
- The DHCP daemon may simply crash and restart, limiting persistence
- MIPS exploitation requires architecture-specific ROP chains or shellcode
Achieve code execution (unconfirmed) or DoS
- Successful stack corruption leading to controlled EIP/PC
- Compatible memory layout (no ASLR on this platform makes this more likely)
- Consumer router with limited onboard tooling for post-exploitation
- Blast radius is confined to the local segment behind the compromised router
- Enterprise monitoring of DNS/traffic anomalies would detect pivoting
The supporting signals.
| In-the-Wild Exploitation | None confirmed. No reports of active exploitation in the wild. Not listed on CISA KEV. D-Link advisory SAP10516 notes the flaw is under investigation. |
|---|---|
| Proof of Concept | Public PoC available. Published by researcher *anoymask* on dev.to. Demonstrates stack overflow via crafted DHCP option 125 payload. Stable RCE not confirmed — DoS (daemon crash) is the proven outcome. |
| EPSS Score | 0.01346 (1.35%) — low exploitation probability. Consistent with adjacent-network-only, consumer-device vulnerability. |
| KEV Status | Not listed. No CISA KEV entry as of 2026-09-23. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — noisgate disputes AV:N. DHCP is a Layer 2 protocol; the correct vector should use AV:A (Adjacent Network). Even corrected to AV:A, base score is 9.6, but real-world enterprise relevance is far lower. |
| Affected Versions | D-Link DIR-822A firmware A_101 (non-US hardware revisions, A and B). Sold in Middle East, Asia-Pacific, and other non-US regions. |
| Fixed Version | None. Device is End of Life / End of Service Life. D-Link has stated no firmware patches will be released. Advisory SAP10516 recommends device retirement and replacement. |
| Scanning / Exposure | No Shodan/Censys/GreyNoise data specifically tracking DIR-822A population. The device is a consumer SOHO router — internet-facing management interfaces are uncommon. DHCP attack surface is LAN-only by protocol design. |
| Disclosure Date | 2026-09-07 (CVE published). D-Link advisory SAP10516 published 2026-09-18, updated 2026-09-21. |
| Reporter | Researcher handle anoymask. Published technical writeup and PoC on dev.to. Also reported CVE-2026-86510 (L2TP OOB write, CVSS 9.9) affecting the same device. |
Why this verdict
- Misstated attack vector drops the effective score. The CVSS vector uses
AV:N(Network) but DHCP is a Layer 2 broadcast-domain protocol. The attacker must be on the same LAN segment — this is textbookAV:A(Adjacent Network). Correcting this alone drops the base score from 10.0 to 9.6, and the real-world exploitability drops dramatically because the attacker must already have local network access. - LAN adjacency implies post-initial-access. Requiring the attacker to be on the same broadcast domain means they either have physical access, cracked the Wi-Fi PSK, or already compromised a host on the segment. In an enterprise, this means the attacker has already bypassed perimeter controls — the router overflow is a secondary pivot, not an initial access vector.
- Consumer SOHO router with negligible enterprise footprint. The DIR-822A is a ~$30 consumer Wi-Fi router sold in non-US markets. It is not enterprise network equipment. An organization managing 10,000 hosts is vanishingly unlikely to have DIR-822A units in its managed asset inventory. Any instances would be rogue devices or remote worker home routers outside the enterprise control plane.
- RCE is unconfirmed — DoS is the proven impact. Multiple sources note that 'stable code execution has not been confirmed in public information.' The PoC demonstrates a daemon crash. While the lack of ASLR on MIPS makes RCE plausible, the confirmed impact today is service disruption, not full compromise.
- Role multiplier: no high-value-role floor triggers. The DIR-822A is a consumer SOHO router, not a network edge appliance (F5, FortiGate, PAN-OS), identity provider, hypervisor, or any other high-value-role component. (a) *Low-value role (home/branch Wi-Fi)*: the chain succeeds with host-level blast radius limited to the single router and its connected clients. (b) *Typical role*: this device has no typical enterprise role — it is consumer gear. (c) *High-value role*: the DIR-822A does not occupy any high-value role in enterprise deployments. Even in the worst case (compromised home router of a remote worker), the blast radius is confined to the home LAN segment and does not extend to domain, fleet, or supply-chain impact. The high-value-role floor of HIGH does not apply.
- No in-the-wild exploitation, no KEV listing, low EPSS. At 1.35% EPSS with no confirmed exploitation, this vulnerability is not being actively weaponized. The LAN-adjacency requirement makes mass scanning impossible — unlike internet-facing vulns, this cannot be sprayed from the internet.
Why not higher?
A HIGH or CRITICAL rating would require either confirmed active exploitation, a viable internet-facing attack vector, or deployment in a high-value enterprise role. None of these conditions are met. The DIR-822A is a consumer SOHO device that does not appear in enterprise asset inventories, the attack is confined to the local LAN segment (not internet-reachable), and RCE has not been confirmed. The vendor's CVSS 10.0 reflects theoretical worst-case impact on the device itself, not real-world enterprise risk.
Why not lower?
A LOW or IGNORE rating would undercount the risk for the edge case where DIR-822A units exist as rogue devices or in branch offices. The public PoC lowers the exploitation bar, the lack of ASLR on MIPS makes eventual RCE plausible, and the device being EOL with no patch means the vulnerability is permanent until the hardware is removed. If you have these devices, they are unremediable attack surface.
What to do — in priority order.
- Discover and decommission all DIR-822A units immediately — Run an asset discovery sweep (network scan for D-Link OUI
00:AD:24,28:EE:52,FC:75:16; SNMP/UPnP device fingerprinting; wireless survey for DIR-822A SSIDs). Any units found should be physically removed and replaced with supported hardware. Since this is a MEDIUM verdict with no mitigation SLA, go straight to the 365-day noisgate remediation window — but given the device is EOL with no patch, replacement is the only action and should be prioritized in your next hardware refresh cycle. - Enable DHCP snooping on all managed switches — DHCP snooping on enterprise switches will drop DHCP traffic from untrusted ports, preventing rogue DHCP packets from reaching any DIR-822A units on managed segments. This is a defense-in-depth measure that also protects against DHCP-based attacks on other devices.
- Enforce 802.1X / NAC on all switch ports — Network Access Control prevents unauthorized devices (including rogue consumer routers) from connecting to enterprise LAN segments. This blocks the attacker's prerequisite of LAN adjacency on managed network segments.
- Segment any remaining consumer devices behind a quarantine VLAN — If immediate removal is not feasible, isolate DIR-822A units in a dedicated VLAN with no access to production resources. Apply strict ACLs to limit lateral movement from the quarantine segment.
- Firmware patching — the DIR-822A is End of Life. D-Link has explicitly stated no firmware updates will be released. There is no patch to apply, now or ever.
- WAF / IPS signatures — this is a DHCP Layer 2 attack, not an HTTP/application-layer exploit. Web application firewalls and most IPS rulesets do not inspect DHCP option fields at the broadcast-domain level.
- Disabling remote management — while D-Link recommends this, it does not address the DHCP attack vector. The vulnerability is in the DHCP daemon, not the web management interface. Disabling remote admin is good hygiene but irrelevant to this specific CVE.
Crowdsourced verification payload.
Run this script from any Linux/macOS host on the same network segment as the suspected DIR-822A device. Pass the target router's IP as the first argument: sudo bash check_dir822a.sh 192.168.0.1. Requires curl or wget and nmap (for UPnP fingerprinting). No authentication needed — the script probes UPnP and HTTP headers to identify the device model and firmware.
#!/usr/bin/env bash
# check_dir822a.sh — Detect D-Link DIR-822A with vulnerable firmware A_101
# Usage: sudo bash check_dir822a.sh <router-ip>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
set -euo pipefail
TARGET="${1:?Usage: $0 <router-ip>}"
VULN_MODEL="DIR-822A"
VULN_FW="A_101"
echo "[*] Checking $TARGET for D-Link DIR-822A (CVE-2026-86296)..."
# Method 1: HTTP server header / body fingerprinting
HTTP_RESP=$(curl -skL --max-time 10 "http://$TARGET/" 2>/dev/null || true)
if echo "$HTTP_RESP" | grep -qi "DIR-822A"; then
echo "[+] HTTP fingerprint: DIR-822A detected"
MODEL_FOUND=true
else
MODEL_FOUND=false
fi
# Method 2: UPnP SSDP fingerprinting
if command -v nmap &>/dev/null; then
UPNP_RESP=$(nmap -sU -p 1900 --script=upnp-info "$TARGET" 2>/dev/null || true)
if echo "$UPNP_RESP" | grep -qi "DIR-822A"; then
echo "[+] UPnP fingerprint: DIR-822A detected"
MODEL_FOUND=true
fi
fi
# Method 3: Check HNAP endpoint (D-Link specific)
HNAP_RESP=$(curl -skL --max-time 10 "http://$TARGET/HNAP1/" 2>/dev/null || true)
if echo "$HNAP_RESP" | grep -qi "DIR-822A"; then
echo "[+] HNAP fingerprint: DIR-822A detected"
MODEL_FOUND=true
# Try to extract firmware version from HNAP
FW_VER=$(echo "$HNAP_RESP" | grep -oiP '(?<=<FirmwareVersion>)[^<]+' || true)
if [ -n "$FW_VER" ]; then
echo "[*] Firmware version reported: $FW_VER"
fi
fi
if [ "$MODEL_FOUND" = true ]; then
# Check for firmware version A_101
if echo "$HTTP_RESP $HNAP_RESP" | grep -qiE "A_101|A1\.01|1\.01"; then
echo ""
echo "==> VULNERABLE"
echo " Device: D-Link DIR-822A firmware A_101"
echo " CVE: CVE-2026-86296 (stack-based buffer overflow in udhcpcd)"
echo " Status: End of Life — no patch available. Replace this device."
exit 1
else
echo ""
echo "==> VULNERABLE (assumed)"
echo " Device: D-Link DIR-822A detected but firmware version could not be confirmed."
echo " All DIR-822A units are EOL and should be replaced regardless of firmware."
exit 1
fi
else
# Check if it's any D-Link device
if echo "$HTTP_RESP $HNAP_RESP $UPNP_RESP" | grep -qi "D-Link\|dlink"; then
echo ""
echo "==> PATCHED (not a DIR-822A)"
echo " Device appears to be a D-Link product but not the affected DIR-822A model."
exit 0
else
echo ""
echo "==> UNKNOWN"
echo " Could not fingerprint device at $TARGET as D-Link DIR-822A."
echo " Verify manually or check MAC OUI against D-Link prefixes (00:AD:24, 28:EE:52, FC:75:16)."
exit 2
fi
fi- BleepingComputer — D-Link warns of max severity zero-day bug in DIR-822A routers
- anoymask — Pre-authentication DHCP Buffer Overflow PoC writeup
- GBHackers — D-Link DIR-822A Router Vulnerability Scores CVSS 10.0
- D-Link Support Announcement — Legacy Routers End of Life
- SecurityOnline — D-Link DIR-822A Vulnerabilities Details and PoC Disclosed
- CyberSecurityNews — D-Link Router Hit by CVSS 10.0 Flaw
- VulDB — CVE-2026-86296 Entry
- GovInfoSecurity — D-Link Flags Max Severity Zero-Day in Legacy Router
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.