← Back to Feed CACHED · 2026-09-23 04:49:56 · CACHE_KEY CVE-2026-86296
CVE-2026-86296 · CWE-119 · Disclosed 2026-09-07

A vulnerability was determined in D-Link DIR-822A A_101.

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

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.

"A CVSS 10.0 on a consumer router you almost certainly don't own. Replace any strays; don't lose sleep."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker gains LAN adjacency

The attacker must be on the same Layer 2 broadcast domain as the DIR-822A router. DHCP operates over UDP ports 67/68 and is inherently a local-segment protocol — packets are not routable across subnets without a DHCP relay. This means the attacker needs physical or wireless access to the same network the router serves, or must have already compromised a host on that segment.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Rogue device detection via NAC or wireless IDS would flag an unauthorized DIR-822A. DHCP snooping on managed switches would detect anomalous option 125 payloads.
STEP 02

Craft malicious DHCP packet with option 125 payload

The attacker constructs a DHCP packet containing a vendor-specific option 125 subfield with data exceeding 256 bytes. The public PoC reportedly demonstrates this crafting. The payload exploits the TR-111 parsing logic that treats length-delimited binary fields as null-terminated C strings, allowing unbounded strcpy into a fixed stack buffer.
Conditions required:
  • Knowledge of the vulnerability (public PoC available)
  • Ability to send raw DHCP packets on the LAN
Where this breaks in practice:
  • DHCP snooping on enterprise switches would drop untrusted DHCP traffic
  • VLAN segmentation isolates the blast radius to the local segment
Detection/coverage: DHCP snooping logs on managed switches. IDS signatures for anomalously large option 125 fields.
STEP 03

Trigger stack buffer overflow in udhcpcd

When the DIR-822A's DHCP daemon processes the crafted packet, 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.
Conditions required:
  • DIR-822A running firmware A_101 with vulnerable udhcpcd
  • No ASLR/stack canaries on this MIPS-based consumer firmware (typical for this device class)
Where this breaks in practice:
  • The DHCP daemon may simply crash and restart, limiting persistence
  • MIPS exploitation requires architecture-specific ROP chains or shellcode
Detection/coverage: The router itself has no logging or monitoring capability that would alert an enterprise SOC. Detection depends on observing the router going offline or DHCP service interruption.
STEP 04

Achieve code execution (unconfirmed) or DoS

If RCE succeeds, the attacker runs as root on the router's embedded Linux OS. This gives full control of the device — DNS hijacking, traffic interception, lateral movement staging. If only DoS is achieved, the DHCP daemon crashes, disrupting network connectivity for all clients behind the router. No public report has confirmed stable, reliable code execution from this overflow.
Conditions required:
  • Successful stack corruption leading to controlled EIP/PC
  • Compatible memory layout (no ASLR on this platform makes this more likely)
Where this breaks in practice:
  • 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
Detection/coverage: DNS anomaly detection, NetFlow analysis for unexpected traffic patterns from the router's IP. No on-device detection capability exists.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone 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 ConceptPublic 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 Score0.01346 (1.35%) — low exploitation probability. Consistent with adjacent-network-only, consumer-device vulnerability.
KEV StatusNot listed. No CISA KEV entry as of 2026-09-23.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hnoisgate 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 VersionsD-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 VersionNone. 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 / ExposureNo 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 Date2026-09-07 (CVE published). D-Link advisory SAP10516 published 2026-09-18, updated 2026-09-21.
ReporterResearcher 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.
04 · The Call

Final Verdict
DOWNGRADED to MEDIUM (5.0/10)

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 textbook AV: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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Sources

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.