Is CVE-2021-45382 (D-Link Multiple Routers Remote Code Execution) being exploited in the wild?

What “being exploited in the wild” means for this D-Link router CVE

For a router flaw like CVE-2021-45382, “being exploited in the wild” means defenders should treat it as an active attack path, not a theoretical weakness. The practical question is whether any exposed D-Link router still has the vulnerable DDNS code path reachable from the internet or from a trusted internal network segment. If so, the asset is already in the high-risk set and needs immediate attention.

A useful first check is whether the device is still internet-facing, whether the DDNS feature is enabled, and whether the model or hardware revision is listed in the vendor advisory and in the CISA Known Exploited Vulnerabilities Catalog. For exploited router CVEs, exposure often matters more than the exact exploit details because these devices are commonly reachable, lightly monitored, and used as a foothold for later intrusion.

For broader triage discipline, use the same approach you would for any actively exploited flaw: validate inventory, confirm exposure, then decide whether you can patch, mitigate, or isolate the device. NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is a useful companion when a KEV-listed issue must be handled as an emergency response rather than a routine maintenance task.

Why router exploitation is operationally dangerous

Remote code execution in a router is high impact because the device sits on a traffic choke point and often has privileged visibility into DNS, session metadata, and internal routing. An attacker who can execute code on the box can usually turn a small external weakness into persistent access, traffic redirection, or a staging point for further compromise.

D-Link router exploitation also tends to matter beyond the device itself. A compromised perimeter router can be used to tamper with outbound connections, redirect users to malicious infrastructure, or support follow-on attacks against internal services that were never meant to be exposed to the internet. That is why active exploitation in KEV should be treated as a network trust problem, not just a firmware bug.

When you are prioritizing response, think in terms of blast radius: if the router supports multiple sites, remote users, or business-critical paths, compromise can affect availability and trust at the same time. The fact that CISA listed the CVE is the operational signal that exploitation is not hypothetical; the device may already be in adversary targeting sets.

What to do before patching, and what to verify after

Start by identifying every affected router instance, including spare units and rarely used branch devices. Then verify whether the DDNS function is enabled, whether management interfaces are exposed externally, and whether any unusual configuration changes or outbound connections appeared around the period of possible exposure.

If patching is delayed, reduce exposure immediately by removing internet-facing management, disabling unnecessary remote services, restricting administrative reachability to trusted source IPs, and placing the device behind stronger monitoring. If the router cannot be confidently secured, replace or isolate it rather than leaving it in a partially trusted state.

After remediation, confirm the device is running the vendor-provided fix or mitigation, then review logs and network telemetry for signs of prior compromise. For edge devices, the absence of obvious alerts is not reassuring on its own, because attackers often use the router to blend into normal network noise. NHIMG’s Vulnerability Management Guide is relevant here because it stresses verification, exception handling, and post-remediation checking rather than assuming a patch alone closes the case.

Risk and Threat Considerations

Active exploitation of a router RCE creates a dual risk: immediate compromise of a perimeter device and downstream exposure of the network segments it brokers. Because routers are often long-lived and under-instrumented, attackers may preserve access after the initial exploit by altering routing, DNS, or management settings.

Failure mechanism: An attacker reaches the DDNS-related code path on an exposed D-Link router, triggers remote code execution, and uses that foothold to alter traffic handling or maintain persistence.

Impact: The device can become a launch point for lateral access, traffic manipulation, credential interception, or service disruption across the connected environment.

Practitioner Guidance

What to prioritise: Treat any internet-exposed or branch-edge D-Link router with this CVE as urgent, even if you have not observed obvious abuse. Exposure plus KEV listing is enough to justify emergency handling.

What to verify: Confirm the exact model and hardware revision, whether the DDNS function is enabled, whether remote admin is reachable from the internet, and whether the unit shows unexpected DNS, routing, or configuration changes.

Decision rule: If patching cannot happen quickly, isolate the router or remove it from service rather than allowing it to remain partially trusted. For edge infrastructure, a delayed fix is often riskier than a controlled replacement.

Practitioner takeaway: For actively exploited router CVEs, the real question is not only whether a fix exists, but whether the device has already become part of your trust boundary problem.

Related resources from NHI Mgmt Group

• Guide: IoT Security Guide
• CVE-2021-45382 (D-Link Multiple Routers Remote Code Execution)
• Is CVE-2021-1647 (Microsoft Defender Remote Code Execution) being exploited in the wild?
• Is CVE-2019-16057 (D-Link DNS-320 Remote Code Execution) being exploited in the wild?
• Is CVE-2018-0125 (Cisco VPN Routers Remote Code Execution) being exploited in the wild?