Join our Newsletter — 33% off our NHI Course

How do you patch or mitigate CVE-2020-15415 (DrayTek Multiple Vigor Routers OS Command Injection)?

CISA’s required action for CVE-2020-15415 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of DrayTek Multiple Vigor Routers in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

What you need to verify before touching the router fleet

The first step is inventory, not patching. Confirm which DrayTek Multiple Vigor Routers are deployed, where they sit, and whether any are reachable from the internet. For CVE-2020-15415, the practical question is whether you can apply the vendor’s mitigation or security update cleanly on every exposed instance, or whether the device must be isolated or retired.

If the router is still business-critical, treat its external exposure as part of the remediation decision. Internet-facing admin interfaces, remote management features, and unsupported deployments increase the chance that a command injection flaw becomes an immediate entry point. That is why confirmed exposure matters before you decide whether a maintenance window is enough.

For broader vulnerable-device context and prioritisation, use the Vulnerability Management Guide to align the response with asset scope, verification, and remediation tracking.

Apply the vendor fix, or reduce exposure until you can

The correct remediation path is to follow the vendor’s instructions for the affected router model and firmware, then verify that the command-injection path is no longer reachable. If a fix cannot be applied immediately, remove the product from direct internet access, disable unnecessary remote administration, and place compensating network controls around it until you can complete remediation or replacement.

For command injection issues, the main operational mistake is to assume that “non-default” settings are enough. Any management surface that remains reachable may still be enough for abuse if the flaw is present. In practice, that means you should validate the actual reachable attack surface after the change, not just confirm that the patch was installed.

Use Web Application Attacks Guide for the attack pattern behind OS command injection and the security checks that matter when verifying the fix.

When the product must stay online during a delay, the CISA KEV record is the authoritative place to confirm the expected remediation posture and timing, while the vendor advisory should provide the specific mitigation steps for the model in use. The CISA Known Exploited Vulnerabilities Catalog is the right reference point for that operational pressure.

How to confirm you actually contained the problem

After patching or mitigation, do not stop at “device updated.” Recheck whether the router is still exposed on the same services, whether administrative access is still reachable from untrusted networks, and whether any adjacent systems depended on the vulnerable path. If the device was internet-facing before remediation, assume it may have been probed and review logs and configuration changes around the exposure window.

If you cannot verify the timeline cleanly, treat the device as potentially compromised until proven otherwise. That means checking for unexpected configuration changes, new accounts or credentials, altered forwarding rules, and any evidence that the router was used as a pivot point into the internal network. If those checks are inconclusive, the safer option is replacement rather than extended reliance on a device whose trust boundary was already crossed.

For current vulnerability records and product details, cross-check the affected CVE entry in NIST National Vulnerability Database and the canonical record in CVE Program.

Standards & Framework Alignment

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

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
CIS Controls v8 CIS-12 — Network Infrastructure Management Covers router exposure, secure configuration, and controlled remediation of network devices.
Recommendation — Harden router management surfaces and remove unnecessary external access paths.
NIST SP 800-53 Rev 5 SI-2 — Flaw Remediation Directly governs applying vendor fixes and tracking remediation for exploitable flaws.
AC-17 — Remote Access Applies to limiting remote management exposure on internet-reachable routers.
RA-5 — Vulnerability Monitoring and Scanning Supports confirming exposure and validating that vulnerable instances are identified.
Recommendation — Apply the vendor fix and track remediation until the flaw is closed. Restrict remote management to trusted paths and approved administrators. Scan for all deployed routers and verify which ones remain exposed.
ISO/IEC 27001:2022 A.8.8 — Management of technical vulnerabilities Matches the need to identify, remediate, and track a known exploited vulnerability.
Recommendation — Track the router flaw through remediation and verify closure before acceptance.

Practitioner Guidance

What to prioritise: Prioritise internet-facing devices first, then any router that supports business-critical connectivity, because those instances have the shortest path from vulnerability to impact. If you cannot patch them immediately, the interim goal is to remove remote reachability, not to keep the same exposure and hope monitoring will catch abuse.

What to verify: Verify three things after remediation, the vendor fix or mitigation was applied, the management surface is no longer externally reachable where it should not be, and the device shows no unexpected post-change behaviour. If any one of those checks fails, treat the case as unresolved.

Practitioner takeaway: For CVE-2020-15415, the decision is not whether to patch, it is whether you can remove the command-injection exposure fast enough to prevent abuse while preserving service continuity.