← Back to Feed CACHED · 2026-10-26 05:41:08 · CACHE_KEY CVE-2021-27137
CVE-2021-27137 · CWE-121 · Disclosed 2026-07-16

DD-WRT UPnP SSDP M-SEARCH stack-based buffer overflow via oversized ST:uuid: value

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

Like leaving a spare key under the mat in a house that most enterprise neighborhoods don't build — but the burglars have a map of every mat

CVE-2021-27137 is a textbook stack-based buffer overflow in the UPnP SSDP handler (ssdp_msearch) of DD-WRT open-source router firmware, affecting all builds before SVN changeset r45724. An attacker on the same LAN segment — or, if UPnP has been misconfigured to bind the WAN interface, from the internet — can send a crafted M-SEARCH UDP packet to port 1900 with an oversized ST:uuid: value. The strcpy call copies this attacker-controlled string into a 128-byte stack buffer with no bounds check, smashing the stack and delivering arbitrary code execution as root on the router. The vulnerability was originally disclosed around March 2021 and patched the same day in changeset r45724, but the CVE record was not formally published in NVD until July 16, 2026 — a five-year gap that left the flaw in a documentation dead zone. In March 2026, FortiGuard Labs discovered the C0XMO botnet (a Gafgyt variant) weaponizing this exact CVE to recruit DD-WRT routers into a DDoS fleet. CISA added it to the KEV catalog on July 21, 2026 with an aggressive 3-day remediation deadline.

The vendor's HIGH 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) is broadly honest for the product class. The AC:H correctly penalizes the fact that UPnP must be explicitly enabled — it ships *off* by default. Where the score slightly oversells the risk to enterprise defenders is the AV:N metric: by default UPnP only listens on *internal* interfaces, meaning the realistic attack vector for most DD-WRT deployments is adjacent-network (AV:A), not full network (AV:N). That single metric swap drops the CVSS to ~7.5. The active C0XMO campaign confirms that real-world exploitation is happening, but the campaign targets SOHO and small-office routers where owners enabled UPnP and never patched — not enterprise-managed infrastructure. For a team managing 10,000 hosts, the immediate question is: *do you even have DD-WRT devices on your network?* If not, this is a documentation exercise. If you do — especially in branch offices or remote-worker home gateways — the KEV listing and active botnet exploitation demand immediate attention.

"Actively botnetted DD-WRT stack smash — disable UPnP immediately if you run this firmware"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Discover DD-WRT target with UPnP enabled

The attacker scans the target network (LAN or, in misconfigured setups, WAN) for UDP port 1900 SSDP responders. DD-WRT routers with UPnP enabled will respond to standard SSDP M-SEARCH discovery requests, revealing the device's UPnP description URL and confirming the attack surface. The C0XMO botnet automates this across address ranges using multi-architecture scanner payloads.
Conditions required:
  • Target runs DD-WRT firmware before r45724
  • UPnP is enabled on the target (off by default)
  • Attacker has network reachability to the UPnP listener (LAN by default)
Where this breaks in practice:
  • UPnP is disabled by default in DD-WRT — the admin must have explicitly turned it on
  • UPnP binds to LAN interfaces only by default, requiring the attacker to already be on the same subnet or the admin to have reconfigured WAN binding
  • Enterprise environments rarely deploy DD-WRT; this is consumer/SOHO firmware
Detection/coverage: Shodan/Censys queries for ssdp + DD-WRT can identify WAN-exposed instances. Internally, a UDP 1900 service enumeration sweep identifies LAN-exposed UPnP listeners.
STEP 02

Send crafted M-SEARCH with oversized ST:uuid: payload

The attacker sends a single UDP datagram to port 1900 containing an M-SEARCH request where the ST:uuid: field exceeds 128 bytes. The ssdp_msearch function in router/upnp/src/ssdp.c calls strcpy() to copy this value into a fixed 128-byte stack buffer without any length validation. The oversized value overwrites the saved return address and adjacent stack frames. The C0XMO botnet packages architecture-specific ROP chains or shellcode for ARM, MIPS, PowerPC, SuperH, x86, and x86_64 targets.
Conditions required:
  • Network path to UDP 1900 on the target
  • Knowledge of target CPU architecture (for reliable shellcode)
Where this breaks in practice:
  • Exploit must be tailored to the specific CPU architecture of the router — DD-WRT runs on many different SoCs
  • Stack layout may vary across DD-WRT build revisions, requiring multiple exploit variants
  • Some DD-WRT builds may have non-executable stack (though many embedded targets lack full NX/ASLR)
Detection/coverage: Network IDS with a signature for oversized SSDP M-SEARCH ST:uuid: fields (>128 bytes) can detect the payload. Snort/Suricata rules targeting anomalous SSDP payloads on UDP 1900 are effective here.
STEP 03

Achieve root code execution on the router

The stack smash redirects execution to attacker-controlled shellcode or a ROP chain. Since DD-WRT's UPnP daemon runs as root, code execution grants full control of the router with no privilege escalation needed. The attacker can now manipulate routing tables, DNS settings, iptables rules, and intercept all traffic flowing through the device. The C0XMO payload immediately downloads multi-architecture bot binaries from a staging server.
Conditions required:
  • Successful buffer overflow and control-flow hijack
  • Attacker has a payload compatible with the target architecture
Where this breaks in practice:
  • ASLR, if enabled on the DD-WRT build, makes reliable exploitation harder (though many embedded Linux builds have weak or no ASLR)
  • Stack canaries, if compiled in, would terminate the process before the return — but DD-WRT's upnp binary is not built with -fstack-protector in affected versions
Detection/coverage: Post-exploitation indicators: unexpected outbound connections from the router, modified DNS/iptables configuration, new cron entries, unknown processes. FortiGuard published C0XMO IOCs including C2 domains and file hashes.
STEP 04

Establish persistence and botnet enrollment

C0XMO copies itself to hidden directories on the router's tmpfs, installs cron jobs and modifies shell init scripts for persistence across reboots (where flash storage is writable). It then contacts its C2 infrastructure and registers the compromised router as a DDoS node. Uniquely, C0XMO scans running processes and terminates competing botnet clients (Mirai, Mozi, etc.) to claim exclusive control of the device.
Conditions required:
  • Successful code execution from Step 3
  • Outbound internet connectivity from the router (nearly always true for a gateway device)
Where this breaks in practice:
  • DD-WRT routers with read-only firmware partitions limit persistence to tmpfs (lost on reboot)
  • Firmware updates or factory resets will evict the malware
  • Network monitoring detecting C2 beaconing can trigger incident response
Detection/coverage: Monitor for anomalous outbound traffic from router management IPs. FortiGuard's C0XMO report includes C2 IPs and domains for blocklist integration.
03 · Compensating Control

1
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Disable UPnP on all DD-WRT devices immediately — Disabling UPnP completely eliminates the attack surface — the ssdp_msearch handler is never reached if the UPnP service is not running. In DD-WRT, navigate to NAT/QoS → UPnP and set 'UPnP Service' to Disable, or via SSH run nvram set upnp_enable=0 && nvram commit && stopservice upnp. Since KEV-listed with active exploitation, deploy within hours — do not wait for the noisgate mitigation SLA's 30-day HIGH window. This is the single most effective control.
2
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Upgrade DD-WRT firmware to r45724 or later — The definitive fix. Download a build from dd-wrt.com that incorporates changeset r45724 or later and flash it via the DD-WRT web UI or TFTP recovery. Per the noisgate remediation SLA for HIGH, complete within 180 days — but given active botnet exploitation, prioritize this within days, not months. Verify the revision in Administration → Firmware or via SSH (cat /tmp/loginprompt).
3
HIGH 7.5→MEDIUM 5.5
SEVERITY REDUCED
Block UDP 1900 from untrusted networks at upstream firewall — If you cannot immediately patch or disable UPnP, block inbound UDP 1900 at the perimeter or upstream switch ACL to prevent WAN-sourced exploitation. This does NOT protect against LAN-side attackers but eliminates internet-facing exposure. Deploy within hours given KEV status.
4
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Inventory and replace DD-WRT with enterprise-grade equipment — The strategic control. DD-WRT is not enterprise firmware — it lacks centralized management, automated patching, and vendor SLA. Replace DD-WRT devices in any managed environment with enterprise-grade routers/firewalls (Cisco, Fortinet, Palo Alto, etc.) that receive coordinated vulnerability management. This eliminates the entire class of DD-WRT vulnerabilities permanently.
What doesn't work
  • WAF — not applicable; CVE-2021-27137 is exploited via raw UDP packets to port 1900, not HTTP traffic. A web application firewall has no visibility here.
  • Endpoint EDR/AV — DD-WRT is embedded Linux router firmware; no enterprise EDR agent runs on it. Host-based detection is not feasible on the target device itself.
  • Network IDS with default rulesets — generic IDS may not have a signature for oversized SSDP ST:uuid: fields. Custom Snort/Suricata rules would work, but out-of-the-box coverage is unreliable. Don't assume your IDS is catching this without verifying the specific signature.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationYES — actively exploited. The C0XMO botnet (Gafgyt variant) has been weaponizing CVE-2021-27137 since at least March 2026, targeting DD-WRT routers globally. Discovered by FortiGuard Labs; initial campaign traced to a Japanese tech company target, C2 sourced from Germany.
CISA KEV StatusListed. Added 2026-07-21, due date 2026-07-24 (3-day window). BOD 22-01 / BOD 26-04 applies. Forensic triage required. Ransomware use: *unknown*.
Proof-of-ConceptWeaponized. The C0XMO botnet constitutes a full weaponized exploit chain with multi-architecture payloads (ARM, MIPS, PPC, SH, x86, x86_64). GitHub repos tzwlhack/Vulnerability and 0day404/vulnerability-poc contain CVE-2021-27137 writeups. No standalone Metasploit module or Nuclei template found in public indexes.
EPSS0.03995 (~4.0% probability of exploitation in next 30 days), approximately 92nd percentile — higher than ~92% of all scored CVEs. Reflects the active botnet exploitation.
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — 8.1 HIGH. Key: AC:H reflects UPnP-must-be-enabled prerequisite. AV:N is arguably generous; default config is LAN-only (AV:A ≈ 7.5 would be more accurate for most deployments).
Affected VersionsDD-WRT firmware all builds before SVN changeset r45724. This spans all hardware platforms supported by DD-WRT (Broadcom, Atheros, MediaTek, Intel, etc.) — the vulnerable code is in the shared router/upnp/src/ssdp.c module.
Fixed VersionDD-WRT changeset r45724 (committed ~March 2021). All firmware builds incorporating this changeset or later are patched.
Exposure SurfaceShodan indexes ~1.65 million devices responding to SSDP on UDP 1900 globally (all vendors). The DD-WRT subset with UPnP *WAN-exposed* is a small fraction. The primary attack surface is LAN-side, where the attacker is already on the local network or has compromised another LAN device first.
Disclosure TimelineOriginal vulnerability disclosure: ~March 2021. Patch shipped: same day (r45724). NVD/CVE record published: July 16, 2026 — over 5 years later. KEV added: July 21, 2026. The 5-year gap between fix and CVE publication left this in a documentation blind spot.
Discovery CreditOriginal researcher not publicly credited. Active exploitation campaign discovered by FortiGuard Labs (Fortinet), published March 2026.

Sources.

  1. CISA KEV Catalog — CVE-2021-27137
  2. Rapid7 Vulnerability Database — CVE-2021-27137
  3. SecurityAffairs — C0XMO Botnet Competitor-Killing Capability
  4. SecurityAffairs — CISA Adds DD-WRT to KEV
  5. ManageEngine — C0XMO Threat Reference
  6. Tenable — CVE-2021-27137
  7. OpenCVE — CVE-2021-27137 Details
  8. CIRCL Vulnerability Lookup — CVE-2021-27137
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.5/10)

Why this verdict

  • Active exploitation confirms the threat is real. The C0XMO botnet proves this isn't theoretical — the exploit is weaponized with multi-architecture payloads and actively recruiting DD-WRT routers into a DDoS fleet. KEV listing with a 3-day deadline underscores CISA's assessment of operational impact.
  • UPnP-off-by-default is meaningful friction but not a full stop. The CVSS AC:H already accounts for this. However, the population of DD-WRT users who enable UPnP is non-trivial — it's a common consumer action for gaming, media streaming, and IoT device support. The C0XMO campaign's success proves enough targets exist.
  • LAN-only default binding narrows the realistic attack vector. The CVSS AV:N overstates exposure for default configurations. Since UPnP binds to internal interfaces by default, the attacker needs LAN proximity (AV:A) unless the admin explicitly reconfigured WAN binding. This is the primary reason for the 0.6-point score reduction from the vendor's 8.1 to 7.5.
  • Role multiplier: DD-WRT IS a network edge device by definition. Nearly 100% of DD-WRT installations serve as routers/gateways — placing them in the 'network edge appliance' category. A compromised DD-WRT router enables traffic interception, DNS manipulation, NAT rule injection, and pivoting into the LAN. In a SOHO/branch office context, this is a gateway compromise with host-to-segment blast radius. However, the blast radius does not reach 'domain takeover' or 'fleet compromise' directly — it compromises a single network segment and the traffic traversing it. The floor for a network edge device with confirmed exploitation is HIGH.
  • Enterprise deployment footprint is negligible. DD-WRT is consumer/prosumer open-source firmware. An enterprise managing 10,000 hosts is almost certainly running Cisco, Aruba, Fortinet, or Palo Alto — not DD-WRT — on production network infrastructure. The exception is remote-worker home routers or lab environments, which represent <1% of the managed estate. This limits the real-world urgency for most enterprise SOCs.

Why not higher?

A CRITICAL rating would require either unauthenticated remote exploitation with no prerequisites against a default configuration, or a fleet-scale / domain-takeover blast radius. CVE-2021-27137 fails both tests: UPnP must be explicitly enabled (off by default), the listener is LAN-only by default, and the blast radius is limited to a single router and its directly connected network segment. The C0XMO botnet uses compromised routers for DDoS, not for lateral enterprise compromise. DD-WRT's near-zero enterprise deployment footprint further limits the CRITICAL case.

Why not lower?

A MEDIUM or LOW rating would ignore three hard facts: (1) CISA KEV-listed with active exploitation by the C0XMO botnet — this isn't theoretical, (2) the exploit is pre-auth, requires a single UDP packet, and grants root execution — the technical severity is genuinely high for any affected device, and (3) DD-WRT routers are network edge devices by nature, so a successful compromise positions the attacker for traffic interception and lateral movement. The exploitation friction is real but not sufficient to drop below HIGH when a weaponized botnet is actively scanning for targets.

06 · Verification

Crowdsourced verification payload.

Run this script on the DD-WRT router itself via SSH. Example: ssh [email protected] 'sh -s' < check_cve_2021_27137.sh. Requires root SSH access to the device. The script checks the firmware SVN revision against the fixed changeset and reports UPnP status.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/bin/sh
# CVE-2021-27137 Verification — DD-WRT UPnP SSDP Stack Buffer Overflow
# Run ON the DD-WRT router via SSH.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

FIXED_REV=45724

# Confirm this is a DD-WRT device
IS_DDWRT=0
for f in /tmp/loginprompt /etc/motd; do
  [ -f "$f" ] && grep -qi 'dd-wrt' "$f" && IS_DDWRT=1 && break
done
if [ "$IS_DDWRT" -eq 0 ]; then
  nvram get os_version 2>/dev/null | grep -qi 'dd-wrt' && IS_DDWRT=1
fi
if [ "$IS_DDWRT" -eq 0 ]; then
  echo "UNKNOWN - this does not appear to be a DD-WRT device"
  exit 2
fi

# Extract SVN revision number (format: rNNNNN)
REV=""
for src in /tmp/loginprompt /etc/motd; do
  if [ -f "$src" ]; then
    REV=$(sed -n 's/.*r\([0-9][0-9][0-9][0-9][0-9]*\).*/\1/p' "$src" | head -1)
    [ -n "$REV" ] && break
  fi
done
if [ -z "$REV" ]; then
  REV=$(nvram get os_version 2>/dev/null | sed -n 's/.*r\([0-9][0-9][0-9][0-9][0-9]*\).*/\1/p')
fi
if [ -z "$REV" ]; then
  echo "UNKNOWN - could not determine DD-WRT revision number"
  exit 2
fi

# Check UPnP service status
UPNP_NVRAM=$(nvram get upnp_enable 2>/dev/null)
UPNP_PROC=""
pidof upnp >/dev/null 2>&1 && UPNP_PROC="running" || UPNP_PROC="not running"

echo "=== CVE-2021-27137 Check ==="
echo "Device revision:  r${REV}"
echo "Fixed revision:   r${FIXED_REV}"
echo "UPnP nvram:       ${UPNP_NVRAM:-not set} (1=enabled, 0=disabled)"
echo "UPnP process:     ${UPNP_PROC}"
echo "============================"

if [ "$REV" -ge "$FIXED_REV" ] 2>/dev/null; then
  echo "PATCHED - revision r${REV} >= r${FIXED_REV}"
  exit 0
else
  if [ "$UPNP_NVRAM" = "1" ] || [ "$UPNP_PROC" = "running" ]; then
    echo "VULNERABLE - r${REV} < r${FIXED_REV} AND UPnP is ACTIVE"
    exit 1
  elif [ "$UPNP_NVRAM" = "0" ] && [ "$UPNP_PROC" = "not running" ]; then
    echo "VULNERABLE (mitigated) - r${REV} < r${FIXED_REV} but UPnP is disabled"
    exit 1
  else
    echo "VULNERABLE - r${REV} < r${FIXED_REV}, UPnP status inconclusive"
    exit 1
  fi
fi