An Old Router Bug, Newly Exploited: CVE-2021-27137 Lands on the KEV Catalog

A five-year-old buffer overflow in DD-WRT router firmware is being used to spread the C0XMO botnet, and CISA just added it to the Known Exploited Vulnerabilities catalog. Here is how the flaw works, why edge routers matter to the networks behind them, and what our sensors see every day.

What DD-WRT is, and where it sits

DD-WRT is a Linux-based firmware replacement for the routers and wireless access points that sit at the edge of a network. It is popular with home users and small businesses who want features their stock firmware does not offer, and it also turns up on embedded and industrial-grade routers, remote-site gateways, and the kind of always-on wireless gear that quietly links a field location back to a central network. Whatever the label on the box, the job is the same: it is the device standing between the public internet and everything behind it.

That position is exactly what makes an edge router worth an attacker's attention. It is internet-facing by design, it is often forgotten once it is installed, and it frequently runs firmware that has not been updated in years. Compromise one and you get a foothold with a public IP, a persistent Linux host to run from, and a vantage point inside the network it protects. For operational and critical-infrastructure environments, the edge router is one of the bridges between ordinary IT and the sensitive systems further in, which is why we treat consumer-grade and embedded network gear as part of the OT and critical-infrastructure conversation, not separate from it.

How the flaw works

The vulnerability lives in the router's UPnP handling, specifically the SSDP code in router/upnp/src/ssdp.c. UPnP devices announce and discover each other using the Simple Service Discovery Protocol, a small text protocol that runs over UDP on port 1900. A discovery request, called an M-SEARCH, carries a search-target header written as ST: uuid:.... The DD-WRT parser reads the value after uuid: and copies it into an internal, fixed-size buffer using an unsafe strcpy. There is no check that the incoming value fits.

Because the buffer has a fixed size and the attacker controls the length of the input, a long enough ST: uuid: value overruns the buffer and writes past its end into adjacent memory on the stack. In the mild case that corrupts the process and the service crashes, a denial of service. In the serious case a carefully constructed payload steers execution and the attacker runs code in the security context of the router. No login is required, only the ability to send a UDP packet to the UPnP service.

One important caveat keeps this honest. On DD-WRT, UPnP is off by default and, when enabled, it is meant to listen on internal interfaces rather than the public side. The devices most at risk are those where UPnP has been turned on and exposed, whether by configuration choice, by a permissive default on a downstream build, or by the router bridging the service somewhere it should not. That narrows the population, but the internet is large, and scanners find the exposed remainder quickly.

Why it is on the KEV catalog now

A 2021 bug reaching the Known Exploited Vulnerabilities catalog in 2026 is a reminder that exploitation, not disclosure date, is what puts a flaw on that list. The trigger is a botnet. In June 2026, FortiGuard Labs published an analysis of C0XMO, a new variant of the long-running Gafgyt family, that spreads in part by exploiting CVE-2021-27137 against exposed DD-WRT devices.

The threat actor delivered the malware by exploiting CVE-2021-27137, a stack buffer overflow in the UPnP service of vulnerable DD-WRT router firmware versions.

According to that analysis, C0XMO is more modular than earlier Gafgyt strains. Once it lands on a device it downloads architecture-specific binaries, having been compiled for ARM, MIPS, PowerPC, SuperH, MC68000, x86, and AMD64, so a single campaign can infect a wide mix of routers and IoT hardware. It installs persistence through cron jobs that re-run it every fifteen minutes and through entries appended to shell profile files, hides copies in locations such as /tmp/.sys, and kills competing malware and security tooling it finds running. It then connects to a command-and-control server and waits for instructions, supporting a menu of distributed-denial-of-service methods.

Notably, C0XMO splits its spreading logic into a separate Python scanner. That scanner sweeps random internet addresses across a list of common ports, brute-forces weak Telnet and SSH credentials, and carries a set of HTTP exploits for other edge devices, DVRs, and IoT gear alongside the DD-WRT UPnP exploit. The DD-WRT flaw is one initial-access route among several, which is what makes the campaign broad rather than narrow.

The real-world risk

The blast radius has two layers. The first is the router itself becoming a bot: absorbed into a DDoS fleet, burning bandwidth, and serving as a staging point. The second, and the one that matters for the networks behind these devices, is what a compromised edge router enables. An attacker with code execution on the gateway sits at the boundary of the internal network. From there they can watch traffic, pivot to other devices, and brute-force the internal services the router was supposed to shield. C0XMO's own scanner does exactly this kind of internal-and-external credential sweeping once it has a host to run from.

For operational and critical-infrastructure settings, that boundary position is the concern. Remote sites, field equipment, and small facilities are often connected back through exactly this class of inexpensive, long-lived router. A device that has quietly forwarded packets for five years is precisely the sort of thing that never got the 2021 patch. CISA lists known ransomware use for this CVE as unknown, and we have seen no evidence tying it to ransomware, so we will not imply one. The honest framing is a botnet using an old, reliable bug to grow, on a class of device that too often sits between the internet and something that matters.

What our sensors see

We run a fleet of honeypots and edge decoys, so we checked our own data. Un-authenticated scanning for exposed UPnP on UDP 1900 is routine background noise on the internet, and it reaches our sensors continuously. So does the rest of C0XMO's playbook: random-address sweeps against Telnet and SSH on ports like 23 and 22, and probing of web and device-management ports such as 80, 8080, 7547, and 5555. This is the everyday texture of automated botnet growth, and it is exactly the surface our decoys are built to sit in front of.

How to fix and mitigate it

• Update DD-WRT to changeset 45724 or later. The patched build adds the missing bounds handling in the SSDP parser. This is the primary fix. Check the firmware date on every DD-WRT device you run, including the ones you forgot about.
• Disable UPnP unless you truly need it. UPnP is off by default on DD-WRT for a reason. If a device does not need it, turn it off, which removes the vulnerable service entirely.
• Never expose UPnP to the internet. The SSDP service on UDP 1900 should never be reachable from the public side. Block inbound UDP 1900 at the perimeter and confirm the service listens only on internal interfaces.
• Change default and weak credentials. C0XMO also spreads by brute-forcing Telnet and SSH. Disable Telnet, use strong unique passwords or keys for SSH, and close remote-management interfaces you do not use.
• Segment the edge. Keep remote-site and field routers on isolated segments so that a compromised gateway cannot freely reach the sensitive systems behind it. Monitor for unexpected outbound connections and for bursts of SSDP or credential-brute-force traffic.

Reference