Is CVE-2020-1350 (Microsoft Windows DNS Server Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2020-1350 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows DNS Servers fail to properly handle requests, allowing an attacker to perform remote code execution in the context of the Local System Account.

What CISA’s KEV listing tells you about active exploitation

The practical answer to “is it being exploited in the wild?” is yes, because CISA’s KEV catalogue is reserved for vulnerabilities with reliable evidence of active exploitation. For a Windows DNS Server RCE, that means defenders should treat exposure as an immediate response problem, not a theoretical one, and confirm whether any internet-facing or internally reachable DNS servers match the vulnerable product and role.

CISA Known Exploited Vulnerabilities Catalog is the authoritative signal for whether a flaw has crossed from disclosure into active attacker use. Use it to drive urgency, due dates and exception handling rather than waiting for local telemetry to prove compromise first.

Why this DNS Server flaw is operationally dangerous

A DNS service bug with remote code execution impact is especially sensitive because DNS is often both widely exposed and deeply trusted. If an attacker can make the server process unsafe requests in the context of Local System, the blast radius can extend beyond name resolution into full host compromise, service disruption and follow-on access to adjacent infrastructure.

The exposure question is broader than “is this server patched.” You also need to know whether the DNS role is enabled on systems that were not intended to host it, whether the server is reachable from untrusted networks, and whether compensating controls such as isolation, segmentation or restrictive management access were already in place before public exploitation began.

How to validate exposure and check for earlier compromise

Start by inventorying every Windows DNS Server instance, then compare those hosts against the vendor advisory and the KEV catalogue entry for version and remediation details. For any exposed or critical instance, review logs and host telemetry for abnormal service crashes, unexpected child processes, new scheduled tasks, outbound connections or other signs that DNS service context may already have been abused.

Zero-Day and Exploited Vulnerabilities Guide is the right internal playbook when a vulnerability has known in-the-wild exploitation. It frames the triage sequence around exploitability, emergency mitigation, compromise assessment and post-patch hunting instead of treating patching as the only step.

Vulnerability Management Guide supports the operational side of this question: scope the asset, prioritise by active exploitation, verify remediation and retain evidence for exception handling. That is the difference between a routine finding and a live incident.

Risk and Threat Considerations

When DNS servers are exploited, the risk is not limited to one host. A compromise of a name-resolution tier can become a platform for persistence, interception, lateral movement or service interruption because other systems depend on it continuously and often trust it implicitly.

Failure mechanism: The server mishandles crafted requests and executes attacker-controlled code in a high-privilege service context, which can turn a network-facing infrastructure service into a foothold for further compromise.

Impact: Expect possible full host takeover, tampering with DNS behaviour, service outage, and secondary exposure if the server can reach management networks, credentials or other internal services.

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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Actively exploited vulnerabilities require risk-based prioritization and exception handling.
Recommendation — Prioritize KEV-listed exposure using risk criteria and document any accepted exceptions.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question centers on remediation urgency for an exploited software flaw.
	CA-7 — Continuous Monitoring	Active exploitation requires monitoring for signs of compromise and post-exploitation activity.
Recommendation — Patch or mitigate the DNS flaw promptly and verify remediation on all affected hosts. Monitor DNS servers for anomalous processes, crashes and outbound connections after exposure.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-driven triage and exposure confirmation are core vulnerability-management tasks.
	CIS-18 — Penetration Testing	Checking for earlier compromise requires adversary-style validation of exposed systems.
Recommendation — Use KEV status to accelerate scanning, prioritization and remediation verification. Validate whether exposed DNS servers show signs of exploitation or persistence.

Practitioner Guidance

What to prioritise: Treat any internet-facing or business-critical DNS server as urgent until proven otherwise. If patching is delayed, move first on containment, exposure reduction and compromise assessment rather than waiting for perfect change windows.

What to verify: Confirm the server is actually acting as DNS, not just installed with the role, and verify whether any exception, compensating control or maintenance note exists for the affected asset. If you cannot prove it is not exposed, assume it is in scope for action.

Practitioner takeaway: For KEV-listed DNS RCEs, “exploited in the wild” means response urgency is driven by attacker use, not by whether you have yet observed a local alert; inventory, contain and hunt first, then normalise remediation.