Join our Newsletter — 33% off our NHI Course

CVE-2020-1350 (Microsoft Windows DNS Server Remote Code Execution)

CVE-2020-1350 is a DNS server remote code execution vulnerability in Microsoft Windows. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. 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 this vulnerability means in a Windows DNS environment

CVE-2020-1350 is dangerous because it sits in a core network service that many Windows environments treat as trusted infrastructure. When DNS parsing fails in a server process, an attacker can turn ordinary name resolution traffic into a remote code execution path, which can make the vulnerability reachable from places that security teams do not normally treat as application entry points.

That matters because DNS servers often sit on highly available systems with broad network reach. If the service is exposed to hostile traffic, the bug can become a direct path to code execution in a privileged context, which raises the stakes beyond a routine service crash or misconfiguration.

How exposure typically arises

Organisations should first identify every Windows DNS Server instance in production, test, and remote office environments, then confirm whether any instance is reachable from untrusted networks or upstream resolvers. A complete asset inventory matters because the vulnerable service may exist on domain controllers, infrastructure servers, or legacy systems that are not obvious from a single vulnerability scan.

Exposure review should also include vendor advisories and the NIST National Vulnerability Database and CVE Program records for authoritative identifiers and tracking, plus the CISA KEV catalogue referenced in the primary definition. For internet-facing services, even partial exposure can matter because exploitability is driven by who can reach the DNS listener, not only by where the server is hosted.

Remediation and compensating controls

The preferred response is to apply the vendor fix as soon as operationally possible and verify that the DNS role is covered in your patch management process. If patching must be delayed, reduce reachability by restricting inbound access to the service, separating DNS roles from less trusted workloads, and removing any unnecessary exposure at network boundaries.

Controls that help while remediation is pending include tight segmentation around name-resolution infrastructure, limited administrative access, and emergency change handling for systems that provide critical domain services. The practical goal is to shrink the number of systems and users that can touch the vulnerable listener before exploitation is attempted.

Detection and post-patch compromise review

Because the vulnerability enables remote code execution, defenders should treat successful exploitation as a possible precursor to broader compromise, not as a closed event. Review DNS server logs, system telemetry, new services or scheduled tasks, and any unusual child processes launched by the DNS service account context.

After patching, confirm whether the server was already touched before the fix was applied. If exploitation is suspected, review adjacent systems for lateral movement, persistence, and any credentials, sessions, or service tokens that may have been accessed from the compromised host. The Vulnerability Management Guide is useful here because it frames verification, prioritisation, and remediation closure as part of the response lifecycle.

Risk and Threat Considerations

DNS is a high-trust service, so a remote code execution flaw in that layer can create disproportionate impact. Attackers value this type of bug because it can provide a foothold on infrastructure that is broadly reachable, highly privileged, and often monitored less aggressively than user-facing applications.

Failure mechanism: Malformed or specially crafted requests are processed incorrectly by the DNS service, allowing attacker-controlled input to trigger code execution in the service process.

Impact: Successful exploitation can lead to full server compromise, service disruption, and downstream exposure of infrastructure trust relationships that depend on that DNS host.

Standards & Framework Alignment

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

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

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 SI-2 — Flaw Remediation DNS RCE requires timely remediation and verification.
SC-7 — Boundary Protection Limiting reachability reduces exploit exposure for the DNS service.
Recommendation — Prioritise SI-2 to track, test, deploy, and verify the fix on all Windows DNS servers. Apply SC-7 to restrict who can reach the DNS listener and reduce external exposure.
CIS Controls v8 CIS-7 — Continuous Vulnerability Management CVE-2020-1350 is a known exploited vulnerability requiring disciplined prioritisation.
CIS-12 — Network Infrastructure Management DNS servers are core network infrastructure and need controlled segmentation and hardening.
Recommendation — Use CIS-7 to inventory affected hosts, prioritise the KEV-listed issue, and confirm remediation. Use CIS-12 to segment and harden DNS infrastructure so exposed listeners are harder to reach.
NIST CSF 2.0 PR.IP-12 — Vulnerability Management Plan This vulnerability needs planned remediation, validation, and closure tracking.
Recommendation — Use PR.IP-12 to ensure the DNS flaw is patched, validated, and tracked to closure.

Practitioner Guidance

Why practitioners should care: Treat DNS servers as critical attack surface, not just supporting infrastructure. A vulnerability in this role can become a high-impact entry point because the service is both network-facing and deeply trusted by the rest of the environment.

What to watch for: Focus on exposure paths, patch status, and evidence of suspicious execution on the DNS host, especially where the server also performs broader directory or infrastructure duties. The Patch Management Guide is a useful operational reference for emergency remediation, verification, and reporting.

Practitioner takeaway: For infrastructure services like DNS, remediation is only complete when exposure is reduced, the fix is verified, and compromise review has been performed.