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.
4 steps from start to impact.
Discover DD-WRT target with UPnP enabled
- 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)
- 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
ssdp + DD-WRT can identify WAN-exposed instances. Internally, a UDP 1900 service enumeration sweep identifies LAN-exposed UPnP listeners.Send crafted M-SEARCH with oversized ST:uuid: payload
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.- Network path to UDP 1900 on the target
- Knowledge of target CPU architecture (for reliable shellcode)
- 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)
ST:uuid: fields (>128 bytes) can detect the payload. Snort/Suricata rules targeting anomalous SSDP payloads on UDP 1900 are effective here.Achieve root code execution on the router
- Successful buffer overflow and control-flow hijack
- Attacker has a payload compatible with the target architecture
- 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-protectorin affected versions
Establish persistence and botnet enrollment
- Successful code execution from Step 3
- Outbound internet connectivity from the router (nearly always true for a gateway device)
- 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
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.cat /tmp/loginprompt).- 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.
The supporting signals.
| In-the-Wild Exploitation | YES — 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 Status | Listed. 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-Concept | Weaponized. 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. |
| EPSS | 0.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 Vector | CVSS: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 Versions | DD-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 Version | DD-WRT changeset r45724 (committed ~March 2021). All firmware builds incorporating this changeset or later are patched. |
| Exposure Surface | Shodan 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 Timeline | Original 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 Credit | Original researcher not publicly credited. Active exploitation campaign discovered by FortiGuard Labs (Fortinet), published March 2026. |
Sources.
- CISA KEV Catalog — CVE-2021-27137
- Rapid7 Vulnerability Database — CVE-2021-27137
- SecurityAffairs — C0XMO Botnet Competitor-Killing Capability
- SecurityAffairs — CISA Adds DD-WRT to KEV
- ManageEngine — C0XMO Threat Reference
- Tenable — CVE-2021-27137
- OpenCVE — CVE-2021-27137 Details
- CIRCL Vulnerability Lookup — CVE-2021-27137
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:Halready 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:Noverstates 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.
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.
#!/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