CVE-2021-27137: DD-WRT Stack-Based Buffer Overflow Vulnerability
An issue was discovered in router/upnp/src/ssdp.c in DD-WRT before 45724. An unsafe strcpy in the UPnP handling functionality allows an unauthenticated remote attacker to send a request that would overflow an internal fixed buffer. Exploitation requires the DD-WRT user to enable UPnP (which is off by default, and only listens on internal interfaces by default). This occurs in ssdp_msearch (reachable by an M-SEARCH request).
CVE-2021-27137 is a stack-based buffer overflow in DD-WRT firmware that can let an unauthenticated attacker overflow an internal buffer used by UPnP and achieve code execution. For teams running DD-WRT on routers or similar network devices, this matters because successful exploitation can give an attacker control of the device and a foothold on the network it serves.
Public detail is limited to the CISA description and the CWE-121 classification. Confirm exact affected builds, fixed releases, and any configuration prerequisites against the vendor advisory before acting.
How it works
This vulnerability is a stack-based buffer overflow (CWE-121). In this class of flaw, input is written into a fixed-size buffer on the stack without adequate bounds checking. When more data arrives than the buffer can hold, adjacent stack memory can be overwritten.
According to the CISA summary, the overflow targets an internal buffer used by UPnP. An unauthenticated attacker who can reach the vulnerable UPnP handling path may supply crafted input that overflows that buffer and triggers code execution. Specific packet formats, offsets, or exploit sequences are not provided in the given facts; treat any public proof-of-concept material with caution and validate behavior only in controlled lab conditions against the vendor’s description.
Because UPnP is often exposed on LAN interfaces and sometimes on WAN interfaces when misconfigured, the practical attack surface depends on how the device is deployed and whether UPnP is enabled and reachable.
Am I affected? How to find it in your systems
DD-WRT is third-party firmware commonly installed on consumer and small-business routers, access points, and similar embedded network gear. Inventory every device that might be running DD-WRT, including lab, branch, and home-office equipment that connects to corporate resources.
- Check device web UI, SSH/CLI banners, or management APIs for the firmware name and version string; record build identifiers exactly as shown.
- Compare those identifiers to the affected and fixed ranges in the vendor advisory—do not assume version numbers from secondary sources.
- Note whether UPnP is enabled and on which interfaces (LAN only, guest, or WAN). Devices with UPnP reachable from untrusted networks are higher priority.
- Review network diagrams and asset databases for “DD-WRT,” custom router firmware, or devices whose stock firmware was replaced.
For exploitation signs, look for unexpected UPnP-related crashes or reboots, anomalous processes or listening ports on the device after a UPnP interaction, and unusual outbound connections originating from the router itself. Embedded devices often have limited logging; forward syslog if available and correlate with network IDS/IPS alerts for malformed or high-volume UPnP traffic. Absence of clear logs does not prove non-exploitation.
How to remediate
Patch first. Apply the vendor-supplied update that addresses CVE-2021-27137, following the installation and verification steps in the official DD-WRT advisory. Confirm the post-update firmware string matches a fixed build.
After patching, harden the device for this weakness class:
- Disable UPnP entirely if you do not need it; if you do, restrict it to trusted LAN segments and never expose it to the internet.
- Ensure management interfaces (web, SSH) are not reachable from untrusted networks and require strong authentication.
- Keep firmware current on a defined schedule and track advisory feeds for DD-WRT.
- Segment router management and IoT/user LANs so compromise of one device does not immediately yield broad internal access.
CISA’s required action directs stakeholders to apply mitigations per vendor instructions, evaluate internet exposure, and follow applicable BOD 26-04 guidance (or discontinue use if mitigations are unavailable). Document compliance for each asset.
If you can't patch immediately
Reduce exposure until you can install the vendor fix:
- Disable the UPnP service on affected devices; this removes the described attack path if the feature is not required.
- Block UPnP-related ports and protocols at the perimeter and on internal firewalls so untrusted hosts cannot reach the service.
- Place vulnerable devices behind stricter network segmentation; avoid direct WAN exposure.
- If a WAF, IPS, or router ACL can filter malformed UPnP traffic, enable vendor or community signatures only after validating they do not break legitimate use—treat this as temporary virtual patching, not a substitute for the firmware update.
- Increase monitoring: alert on device reboots, config changes, new listening services, and unexpected egress from the router’s management address.
Reassess residual risk daily and schedule the official patch as soon as operationally feasible. If no adequate mitigation exists for a given deployment, plan to take the device offline or replace it per CISA guidance.
If your data may have been exposed
Actively exploited vulnerabilities on network edge devices can lead to full device compromise, traffic interception, credential theft, and lateral movement. Known ransomware use is not documented for this CVE in the provided facts; still treat confirmed exploitation as a potential incident. Isolate affected devices, preserve available logs and memory if forensics are required, rotate credentials that traversed the device, and follow your incident-response process. You can run a free exposure scan of your email addresses against known breach data to check whether associated accounts appear in public breach corpora while you complete containment and recovery.
AICompiled with AI assistance from public sources and published under our editorial standards.
Details
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- securityaffairs.com/193290/uncategorized/iot-botnet-c0xmo-adds-competitor-killin
- ssd-disclosure.com/ssd-advisory-dd-wrt-upnp-buffer-overflow/
- svn.dd-wrt.com/changeset/45724
- www.bleepingcomputer.com/news/security/c0xmo-botnet-spreads-via-dd-wrt-router-fl
- www.fortinet.com/blog/threat-research/inside-cross-platform-propagation-of-new-g
- www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-27137