Is CVE-2024-12987 (DrayTek Vigor Routers OS Command Injection) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2024-12987 to its Known Exploited Vulnerabilities catalogue on 15 May 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. DrayTek Vigor2960, Vigor300B, and Vigor3900 routers contain an OS command injection vulnerability due to an unknown function of the file /cgi-bin/mainfunction.cgi/apmcfgupload of the component web management interface.

What makes a router command-injection CVE “exploited in the wild”?

The practical threshold is CISA’s KEV listing, not speculation or proof-of-concept chatter. When a CVE appears in the Known Exploited Vulnerabilities catalogue, it means CISA has found reliable evidence of active exploitation. For defenders, that shifts the question from “is this serious?” to “are we exposed, and can we reduce attack surface fast enough?”

For this type of flaw, the key issue is remote input reaching a privileged command path in the device management interface. If that path is reachable from untrusted networks, the vulnerability can move from theoretical to operational very quickly, especially on exposed edge appliances that are difficult to monitor continuously.

That is why the right starting point is confirmation of exposure, not waiting for a confirmed intrusion alert. If the device is internet-facing, remotely manageable, or reachable from broad internal network segments, treat the KEV designation as a live prioritisation signal and use the vendor advisory plus the CISA Known Exploited Vulnerabilities Catalog for authoritative remediation timing and handling.

For router and appliance flaws, exploitation often matters more than the CVE text alone because the device sits at a trust boundary. That makes even a narrow command-injection condition operationally important: it can lead to device takeover, traffic manipulation, credential capture, or a foothold for deeper network access if the management plane is reachable.

From an asset-management perspective, this is not just a vulnerability record. It is a device-level risk decision about whether the appliance is still fit for service, whether remote administration should remain enabled, and whether compensating controls can actually reduce attackability before remediation is complete.

Why edge-device command injection is high risk

Command injection in a web management interface is dangerous because the attacker does not need a complex exploit chain once the input path is reachable. The flaw sits close to the control plane, so successful exploitation can immediately affect configuration, routing behaviour, or the management environment itself.

In practice, the risk increases when the appliance is treated as “just infrastructure” and gets less logging, weaker segmentation, and slower patch cycles than servers. A router is often a persistence and pivot point, so compromise can outlast the original access path that exposed it.

When defenders look at this class of issue, they should assume the attacker may try for both opportunistic internet exposure and internal lateral movement. Web application attack patterns such as command injection matter here because the management interface is still a web application, even if the target is networking hardware.

What to do if patching or replacement is delayed

If immediate remediation is not possible, the goal is to make the vulnerable management path materially harder to reach and easier to observe. That usually means narrowing administrative access to trusted management networks, removing internet exposure, disabling unnecessary remote management features, and checking whether the device sits where a compromise would have disproportionate blast radius.

Where a router is business-critical, document the exception explicitly and treat it as a temporary exposure with a review date. For appliances in the KEV catalogue, “we will patch later” is not a control; it is only defensible when paired with a concrete compensating reduction in reachable attack surface and a clear rollback or replacement plan.

Use the vendor advisory for version-specific remediation and the KEV entry for prioritisation, then validate the fix against the actual deployed model and configuration. A device can remain vulnerable through management exposure, weak segmentation, or an overlooked branch office deployment even after central teams believe the issue has been addressed.

Risk and Threat Considerations

This CVE is materially risk-bearing because exploitation of a network appliance can expose management access, traffic handling, and the boundary between trusted and untrusted networks. If the interface is reachable, an attacker can move from a simple input flaw to device compromise and potentially to broader internal access.

Failure mechanism: A malicious request reaches the vulnerable CGI management function and is interpreted as an operating-system command instead of safe input, allowing arbitrary command execution through the web interface.

Impact: Successful exploitation can undermine device integrity, enable configuration tampering, and create a foothold for traffic interception, credential theft, or internal pivoting.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-01 — Physical devices and systems inventory	Asset inventory is needed to find affected routers and confirm exposure.
	PR.AA-05 — Network integrity is protected, incorporating network segregation where appropriate	Management-plane segmentation directly reduces exploit reachability for exposed routers.
	DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events	Monitoring is needed to detect exploitation or suspicious management-plane activity.
Recommendation — Inventory all DrayTek appliances and map where the management interface is reachable. Segregate router management access to trusted admin networks only. Monitor router logs and management traffic for anomalous commands and access attempts.
CIS Controls v8	CIS-12 — Network Infrastructure Management	This issue concerns secure administration of network infrastructure devices.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Mitigation depends on hardening exposed device configuration and services.
Recommendation — Restrict and document administrative access to network infrastructure devices. Harden router management settings and remove unnecessary remote access paths.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The management interface is a public-facing application path for command injection exploitation.
Recommendation — Hunt for exploitation attempts against externally reachable management interfaces.
OWASP ASVS	V4 — API and Web Service	The vulnerable CGI management endpoint behaves like a web service input surface.
Recommendation — Treat the management CGI path as a web-service attack surface and validate its inputs.

Practitioner Guidance

What to verify: Confirm whether any DrayTek Vigor devices are deployed, which models are in use, and whether the management interface is reachable from the internet or from broad internal segments. The fastest triage step is exposure mapping, not packet forensics.

Decision rule: If the appliance is reachable from untrusted networks, treat the KEV listing as an immediate remediation priority; if it cannot be remediated right away, isolate management access and reduce who can reach the interface until patching or replacement is complete.

What practitioners underestimate: Edge devices often lack the visibility of servers, so a compromise may not be obvious from normal endpoint tooling. For that reason, review logs, configuration drift, admin account changes, and unexpected outbound connections after remediation, especially if the device handled sensitive traffic.

Practitioner takeaway: For KEV-listed appliance flaws, the key judgement is whether you have actually removed reachable exploitability, not whether the vendor has published a fix in the abstract.

Deepen Your Knowledge

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