Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2020-9377 (D-Link DIR-610 Devices Remote Command Execution)…
Threats, Abuse & Incident Response

Is CVE-2020-9377 (D-Link DIR-610 Devices Remote Command Execution) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2020-9377 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. D-Link DIR-610 devices allow remote code execution via the cmd parameter to command.php. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for CVE-2020-9377

For this CVE, “being exploited in the wild” means the vulnerability has crossed from theoretical exposure into observed attacker use, which is why CISA’s KEV listing matters. The practical question is not whether the flaw exists, but whether any internet-exposed D-Link DIR-610 device should be treated as an active intrusion risk until the issue is removed or the device is isolated.

That distinction is important because remote command execution flaws on edge devices are often used as initial access, not just for one-off compromise. An attacker who can reach the vulnerable cmd parameter in command.php can run operating-system commands with the device’s privileges, which can turn a consumer router into a foothold, pivot point, or surveillance node.

For context on how CISA treats confirmed exploitation, the CISA Known Exploited Vulnerabilities Catalog is the authoritative reference for KEV-listed flaws and the remediation expectations attached to them. If a device still answers on the vulnerable surface, assume exposure until proven otherwise.

Consumer and small-office routers sit at a sensitive boundary: they see inbound traffic, mediate outbound traffic, and are commonly deployed with weak monitoring. When a remote command execution flaw exists on that boundary, the blast radius can extend beyond the device itself into DNS manipulation, traffic redirection, credential capture, or broader internal reconnaissance.

The operational issue is compounded by visibility. Many organisations do not inventory edge appliances with the same discipline they apply to servers or endpoints, so a vulnerable DIR-610 can remain online long after it should have been removed, replaced, or isolated. Once a flaw appears in KEV, that inventory gap becomes a security issue, not just an asset-management one.

For organisations that need a disciplined way to prioritise and verify remediation, the Vulnerability Management Guide covers asset scope, KEV-driven prioritisation, verification, and exception handling. For an actively exploited router flaw, those are the steps that decide whether remediation is real or only assumed.

What to do if patching or replacement is not immediate

If you cannot remove the vulnerable device straight away, the next best move is containment. Place the device behind stricter ingress controls, remove any unnecessary remote administration exposure, and reduce its ability to reach internal systems or sensitive management interfaces. If the device is business-critical, treat the exception as temporary and explicitly time-box it.

Because the weakness is command execution, not just a cosmetic configuration issue, compensating controls should focus on reachability and blast-radius reduction. Network isolation, management-plane restriction, and exposure minimisation are the main levers until the device is replaced or fully remediated.

If you need a broader playbook for confirmed exploitation and emergency response, the Zero-Day and Exploited Vulnerabilities Guide is useful for triage, emergency mitigation, and post-patch hunting. Even when a flaw is no longer a zero-day, the response pattern is similar: reduce exposure first, then verify remediation.

Risk and Threat Considerations

A KEV-listed router RCE creates both exposure risk and threat risk. The device may be compromised silently, used as a staging point for lateral movement, or repurposed for traffic interception, botnet activity, or persistence, especially if it was internet-facing for any meaningful period.

Failure mechanism: An attacker reaches the vulnerable web endpoint, injects commands through the cmd parameter, and executes code on the appliance before defenders notice unusual router behaviour or traffic changes.

Impact: The compromise can expose internal users to redirection, credential theft, service disruption, or follow-on compromise of adjacent systems that trust the network boundary device.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0ID.AM-01 — Identities and Access Management are InventoriedExposed routers must be inventoried before risk can be closed.
PR.PS-01 — Baseline ConfigurationContainment depends on reducing the appliance attack surface and management exposure.
DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity eventsActively exploited edge flaws require monitoring for abnormal traffic and device behaviour.
Recommendation — Inventory all DIR-610 instances and their exposure paths. Harden or isolate the device to reduce reachable attack surface. Monitor router traffic and management activity for compromise indicators.
NIST SP 800-53 Rev 5CM-8 — System Component InventoryYou need an accurate inventory to find vulnerable DIR-610 devices.
SI-4 — System MonitoringConfirmed exploitation requires monitoring for suspicious router behaviour and traffic changes.
Recommendation — Maintain an accurate inventory of all edge appliances and their owners. Alert on anomalous router activity and inbound exploitation attempts.

Practitioner Guidance

What to verify: Confirm whether any D-Link DIR-610 devices are still deployed, whether they are internet-exposed, and whether remote administration or the vulnerable interface is reachable from untrusted networks. If you cannot answer all three quickly, treat that as an exposure gap.

Decision rule: If the device is still in service, replacement is usually the right answer for a KEV-listed edge appliance with command execution, because the residual risk is high and the control surface is small. If replacement must wait, document the exception, isolate the device, and set a firm end date.

What to measure: Track exposure closure, not just patch availability, by confirming external reachability is removed and the device is no longer a trusted path into the environment. For an actively exploited issue, that is the signal that matters most.

Practitioner takeaway: For KEV-listed remote command execution on an edge device, the safe assumption is compromise potential, so the priority is to eliminate exposure or replace the device rather than to debate likelihood.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org