CVE Tools
Sign in
Back to blog

The Router Bug DD-WRT Patched in 2021 Just Became a Botnet's Front Door

CVE-2021-27137 sat fixed and mostly forgotten for five years. In July 2026, CISA put it on the KEV list anyway — because a Gafgyt variant called C0xmo is using it to break into routers, then kill every other botnet it finds already living there.

cve.tools··7 min read
A weathered home router sitting on a shelf, its status LEDs glowing, with faint ghostly overlapping outlines of other malware silhouettes being erased around it — a visual metaphor for one botnet pu
A weathered home router sitting on a shelf, its status LEDs glowing, with faint ghostly overlapping outlines of other malware silhouettes being erased around it — a visual metaphor for one botnet pu

A bug that was supposed to be over

DD-WRT fixed CVE-2021-27137 within days of being told about it, back in March 2021. Nobody wrote it up as a big deal — the flaw needed UPnP enabled (off by default) and, per the researcher's own write-up, an attacker already on the local network. It looked like the kind of bug that quietly dies in a changelog. Five years later, on July 21, 2026, CISA added it to the Known Exploited Vulnerabilities catalog anyway. Not because the bug changed — because a modern IoT botnet called C0xmo started using it as one of its break-in tools, and CISA's job is to flag what's actually being exploited, not what looks urgent on paper.

CVE
CVE-2021-27137An 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 ...
8.1KEV EPSS 4%
5 yearsdisclosure to KEV listingpatched within days in 2021; flagged as exploited in 2026
8.1CVSS 3.1 scoreAV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
96.7th pctEPSS percentile16.5% predicted exploitation likelihood — with zero indexed public PoC

What actually breaks

The flaw lives in router/upnp/src/ssdp.c, DD-WRT's handler for UPnP's SSDP discovery protocol. An M-SEARCH request sent over UDP to port 1900 can carry an ST:uuid: field of arbitrary length. DD-WRT copies that field with an unbounded strcpy into a fixed 128-byte stack buffer — no length check, no truncation. Send more than 128 bytes and you overflow the stack, which is enough for code execution (CWE-121). It was found by independent researcher Selim Enes Karaduman and disclosed through SSD Secure Disclosure on March 24, 2021. DD-WRT's maintainers responded the same way most small open-source projects do when a real bug lands in their inbox — fast: a fix shipped in changeset 45724, days later.

the 2021 disclosure, illustrative
# From SSD Secure Disclosure's public write-up (not a working exploit as reproduced here):# an M-SEARCH request over UDP/1900 with an oversized ST:uuid value —# 164 filler bytes plus a 4-byte return-address placeholder —# crashes DD-WRT's SSDP service within seconds.# The overflow happens in ssdp_msearch(), inside ssdp.c.

The five-year gap, mapped

CVE-2021-27137: disclosure to KEV

  1. Flaw disclosed via SSD Secure Disclosure
    Selim Enes Karaduman reports the ssdp.c buffer overflow; DD-WRT confirms and commits to a fast fix.
  2. DD-WRT ships changeset 45724
    The fix bounds-checks the ST:uuid field. CVE-2021-27137 goes quiet for half a decade.
  3. FortiGuard Labs first observes C0xmo exploiting it
    Initial target: a Japanese technology firm. The attacking source IP traced to an intermediary device in Germany.
  4. Fortinet publishes its technical report on C0xmo
    Researcher Vincent Li details the Gafgyt variant's architecture, propagation exploits and C2.
  5. CISA adds CVE-2021-27137 to KEV
    Listed alongside a Langflow bug (CVE-2026-0770) and two WordPress core CVEs (CVE-2026-63030, CVE-2026-60137).
  6. Federal patch deadline under BOD 26-04
    Now three weeks past, as of this piece.

Meet C0xmo

C0xmo is a variant of Gafgyt (the Bashlite/Lizkebab lineage that, along with Mirai, has powered IoT DDoS botnets for the better part of a decade). Fortinet's write-up is blunt about it standing out from the pack: "a considerably more advanced architecture and feature set compared to earlier IoT botnets." The biggest structural change is that C0xmo splits its lateral-movement logic out into a standalone Python scanner, separate from the compiled bot binary — and that binary itself was compiled for seven different CPU architectures (ARM, MC68000, MIPS R3000, PowerPC, SuperH, Intel 80386, AMD64), which tells you the target list is anything embedded: routers, DVRs, NVRs, and Android devices among them.

How C0xmo spreads and takes over a device

  1. Python scanner sweeps UDP/1900 + Telnet/SSH — Also brute-forces weak Telnet/SSH creds and probes ADB on Android devices
  2. Oversized ST:uuid: in M-SEARCH overflows ssdp.c (CVE-2021-27137)
  3. Payload dropped to /tmp/.cache
  4. Persistence: hidden dirs, cron every 15 min, shell-profile hooks
  5. Scans /proc for rival botnets, security tools, dev utilities
  6. Deletes rival binaries + strips their persistence
  7. Handshake to C2 (magic string + shared secret)
  8. Bot available for 19 DDoS attack commands

The DD-WRT bug is one door out of many

CVE-2021-27137 isn't C0xmo's only way in — it's one entry in a scanner script that also carries exploits spanning more than a decade of embedded-device disclosures. That range is itself the story: none of these individually is new, but bundled together they cover most of what's still plugged in and unpatched on a home or small-office network.

CVE / vectorTargetCVSSDisclosed
CVE-2021-27137DD-WRT UPnP (ssdp.c buffer overflow)8.12021
CVE-2015-2051D-Link DIR-645 HNAP command injection8.82015
CVE-2022-35914GLPI htmLawed PHP code injection9.82022
CVE-2025-34054AVTECH DVR Search.cgi command injection10.02025 (in-the-wild since Jan 2025)
CVE-2016-15047AVTECH CloudSetup.cgi command injection8.82025 (root cause dates to ~2016-17)
No CVE citedZyxel SysTools RCE, NVMS-9000, generic DVR/CGI shell injection——
No CVETelnet/SSH weak-credential brute force, Android ADB abuse——
  • 19 distinct DDoS attack commands, per Fortinet's teardown
  • Volumetric floods: UDP, TCP, SYN, ICMP, ping of death
  • Amplification: NTP and Memcached reflection
  • Game/voice targeting: Discord voice UDP flood, FiveM flood, Valve Source Engine flood
  • Bypass-oriented HTTP floods: Cloudflare-bypass GET flood, OVH-bypass TCP/UDP floods
  • This is a commodity DDoS-for-rent toolkit, not an implant built for espionage or persistence-for-its-own-sake

What to actually do about it

  1. Update DD-WRT to changeset 45724 or later (current stable builds are well past this)
  2. Confirm UPnP is disabled unless you specifically need it — that's DD-WRT's own default
  3. If UPnP must stay on, verify it's bound to LAN-only interfaces and never exposed to the WAN side
  4. Watch for unexplained UDP/1900 traffic spikes, unknown cron entries, or hidden directories named .sys or .cache under /tmp, /var/tmp or /dev/shm
  5. Check outbound connections to Fortinet's reported infrastructure — 85.215.131.70 (C2), 217.160.125.125:15527 (payload/scanner distribution), 176.100.37.91 — treating these as historical indicators, since botnet infrastructure rotates

Data as of 2026-08-17

Tagged
dd-wrtcve-2021-27137iot-botnetgafgytc0xmokevupnpbuffer-overflow