DD-WRT UPnP flaw CVE-2021-27137 added to CISA KEV
CISA added DD-WRT's 2021 SSDP-parsing buffer overflow to KEV on 2026-07-21. Unauthenticated attackers can reach it on routers with UPnP left enabled.
CISA added CVE-2021-27137 to the Known Exploited Vulnerabilities catalog on 2026-07-21. It is a stack-based buffer overflow in DD-WRT’s UPnP handling — an unsafe strcpy in ssdp_msearch — reachable pre-auth from anywhere the router’s SSDP listener is exposed. NVD scores it CVSS 8.1 (high). Fixed in DD-WRT revision 45724 in 2021.
The bug is five years old. The KEV addition is not.
What actually changed
Nothing about the technical picture moved this week. The DD-WRT changeset that landed the fix has been public since 2021, and the exposure profile has not shifted — UPnP is off by default on DD-WRT builds, the SSDP listener binds to internal interfaces by default, and the vast majority of DD-WRT deployments never turn either of those defaults around. Where things get ugly is the intersection: routers where an owner enabled UPnP for a game console, media server, or torrent client and then either (a) never applied the r45724 update, or (b) misconfigured the interface bindings so SSDP became reachable from the WAN. CISA adding the CVE to KEV is the confirmation that attackers are, right now, hitting that intersection at scale — the honest timeline on the actual exploitation is “some time before today,” not the disclosure date.
Preconditions matter — check before you panic
Before priority-calling this over other work, get the facts on the router in front of you:
1. Is UPnP enabled? DD-WRT: Web UI → Services → UPnP. If it says Disabled, this bug is not reachable on this box. Move on.
2. Is the SSDP port (1900/udp) reachable from the WAN side? If UPnP is on but SSDP is bound only to LAN interfaces, external attackers can’t get there. Check the interface binding, not just the on/off switch — misconfigurations here are exactly what pushes an internal-only bug into internet-facing territory.
3. What firmware revision is running? Web UI → Administration → the “DD-WRT” version string. If it’s below r45724, the fix is not installed.
If all three preconditions line up — UPnP on, SSDP reachable externally, firmware below r45724 — this is the highest-priority item on the router’s list. Not because the CVSS score climbed, but because CISA is now saying the population being hit is not hypothetical.
What to actually do
Patch, if the hardware still gets DD-WRT builds. DD-WRT publishes builds per router model; check the DD-WRT router database for the latest build for the specific model. Any recent build carries the r45724 fix.
If the hardware is EOL from DD-WRT’s build tree, treat UPnP as the deprecated feature. Disable UPnP entirely (Services → UPnP → Disable) and configure port forwards manually for the two or three applications that actually need them. That is the honest timeline: an unsupported router with UPnP on and a public SSDP listener is not a defensible configuration in 2026 regardless of which CVE is currently on KEV.
Federal civilian agencies have a deadline. CISA’s KEV additions carry a remediation window under BOD 26-04; the per-CVE due date is on the KEV entry itself. Non-federal orgs aren’t legally bound to it but should treat the same window as a defensible internal target — KEV listings are the closest thing the community has to a shared exploitation-confirmed signal.
Priority call
Patch this ahead of any lower-severity 2026 router-firmware findings on the same asset — a pre-auth stack overflow in a service that’s specifically reachable from the WAN when misconfigured is worse exposure than most of what’s on the router queue this week, regardless of the 2021 CVE number. Deprioritize other UPnP-adjacent audits until you’ve walked the running-firmware list for r45724.
Full technical detail is in the /cve/cve-2021-27137/ entry.
- [ HIGH ] CVE-2021-27137 DD-WRT SSDP Stack-Based Buffer Overflow (UPnP)
Found this useful? Share it.