HowToFixMe
● Critical · CVSS 10 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2020-1350: Remote Code Execution in Windows Server

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 10, Critical
Actively exploited?Yes, listed in CISA KEV (added 2021-11-03)
AffectedWindows Server 2008 SP2, 2008 R2 SP1, 2012, 2012 R2, 2016, 2019, and Server Core releases 1903, 1909, and 2004, only when the DNS Server role is installed and acting as a recursive resolver
Fixed inJuly 2020 Patch Tuesday cumulative updates (released 2020-07-14): e.g. KB4565349, KB4565351, KB4558998, KB4565354, KB4565524, KB4565535, KB4565536. Match the exact KB to your OS build in the MSRC advisory.
Type (CWE)Remote code execution via CWE-20 (Improper Input Validation)

Exploitation status

CVE-2020-1350 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Microsoft Windows DNS Server Remote Code Execution Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: public exploit code is referenced for this CVE, and its place on the CISA KEV catalog confirms working attack code is in active use in the wild, treat weaponization as certain and patch on an emergency timeline.

Authoritative references:

⚠️ Patch immediately. CVE-2020-1350 is in CISA's Known Exploited Vulnerabilities catalog (added 2021-11-03). Federal agencies had until 2022-05-03 to remediate.

What is CVE-2020-1350?

CVE-2020-1350, nicknamed SIGRed, is a remote code execution flaw in the Microsoft Windows DNS Server role. The MITRE record describes it plainly: “A remote code execution vulnerability exists in Windows Domain Name System servers when they fail to properly handle requests.” The root cause is CWE-20, improper input validation. When a Windows DNS server is configured as a recursive resolver and forwards a query upstream, an attacker who controls the answering name server can return a malformed DNS SIG resource record. The length handling for that record overflows, and the attacker turns the overflow into code execution inside the dns.exe service, which runs as SYSTEM.

Two properties make this one of the worst Windows server bugs of its era. First, it is wormable: because Windows DNS servers can query each other, malicious code can spread from resolver to resolver with no user interaction, which is why the CVSS base score is the maximum 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Second, the scope is Changed. code runs as SYSTEM on a domain-facing server, and on a domain controller running the DNS role that means full domain compromise. Note one common confusion: this is remote code execution, not merely denial of service. The publicly posted SIGRed proof-of-concept (linked in the references) only demonstrates a crash, but the underlying overflow is exploitable for RCE, and CISA lists it as actively exploited.

Identify

Only servers with the DNS Server role installed are exposed. A Windows Server with no DNS role, or a workstation, is not affected. Check whether the role is present and whether you are running a recursive resolver:

# Is the DNS Server role installed on this host?
Get-WindowsFeature -Name DNS

# If installed, list the server build and any recursion setting
[System.Environment]::OSVersion.Version
Get-DnsServerRecursion        # ResolvePolicy / Enable values

If Get-WindowsFeature -Name DNS shows the role is not installed, you can stop here, SIGRed does not apply to this machine. If it is installed, treat the host as in-scope and move to the patch step below.

How to fix CVE-2020-1350

The fix is the July 2020 (or any later) cumulative update for your Windows Server build. Microsoft shipped the binary fix on 2020-07-14. There is no separate installer, no third-party package, and no Linux path: Windows DNS Server is a Windows OS component, and you patch it through Windows Update / WSUS / the Microsoft Update Catalog. The exact KB depends on your OS build; the relevant July 2020 KBs are:

Always confirm the exact KB against the MSRC advisory for your precise build, because later cumulative updates supersede these and any of them also closes SIGRed.

Apply the update (PowerShell, run as Administrator)

# Option A: pull the latest cumulative update from Microsoft Update
Install-Module -Name PSWindowsUpdate -Force -Scope CurrentUser
Import-Module PSWindowsUpdate
Get-WindowsUpdate -MicrosoftUpdate -AcceptAll -Install -AutoReboot

# Option B: install a specific .msu you downloaded from the Microsoft Update Catalog
# (replace the KB with the one matching your build from the list above)
wusa.exe C:\Patches\windows10.0-kb4558998-x64.msu /quiet /norestart
Restart-Computer -Force

The DNS service must restart for the fix to take effect, which happens during the post-update reboot. On a clustered or redundant DNS deployment, patch and reboot one node at a time so name resolution stays up.

If you cannot patch in the next hour: the official workaround

Microsoft published a registry workaround that fully blocks SIGRed until the patch lands. It caps the maximum allowable TCP-based DNS response packet at 0xFF00 (65,280) bytes, below the size needed to trigger the overflow. This is the only sanctioned mitigation; it does not break standard DNS but may affect responses larger than 64 KB over TCP. Apply it on every DNS server, then remove it after patching.

# Run on each Windows DNS server, as Administrator
$key = 'HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters'
New-ItemProperty -Path $key -Name 'TcpReceivePacketSize' -Value 0xFF00 -PropertyType DWord -Force
Restart-Service DNS
Get-ItemProperty -Path $key -Name 'TcpReceivePacketSize'
# Expected value: 65280

Verify the fix

After the reboot, confirm a SIGRed-relevant KB is present and that the DNS service is running the patched binary.

# Check for a July 2020 (or superseding) SIGRed KB
$kbs = 'KB4558998','KB4565351','KB4565503','KB4565511',
       'KB4565540','KB4565536','KB4565537','KB4565535',
       'KB4565524','KB4565539','KB4565541'
$hits = Get-HotFix | Where-Object { $_.HotFixID -in $kbs }
if ($hits) {
    Write-Host "SIGRed patch present:" ($hits.HotFixID -join ', ')
} else {
    Write-Warning "No listed SIGRed KB found. A later cumulative update may supersede these, confirm your build's current patch against the MSRC advisory before trusting this result."
}

# Confirm the patched dns.exe version (Server 2019 example: 10.0.17763.1339+ closes SIGRed)
(Get-Item "$env:SystemRoot\System32\dns.exe").VersionInfo.FileVersion

Once the patch is confirmed, remove the registry workaround if you applied it, so DNS responses over 64 KB are no longer truncated:

Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters' -Name 'TcpReceivePacketSize' -Force
Restart-Service DNS

Finally, re-run any vulnerability scanner you used previously and confirm the finding for CVE-2020-1350 has cleared. If the DNS server was internet-reachable during the disclosure window, sweep your logs for the indicators of compromise listed in the vendor and CISA advisories. a SIGRed attack would show as anomalous TCP DNS traffic and an unexpected dns.exe restart or crash.

Frequently asked questions

Which Windows servers are actually vulnerable to SIGRed?

Only servers with the DNS Server role installed and acting as a recursive resolver. That covers Windows Server 2008 SP2 through 2019, plus Server Core 1903, 1909, and 2004. A Windows Server without the DNS role, a domain member that only uses DNS, or any client OS is not affected. Run Get-WindowsFeature -Name DNS to confirm.

Is the registry workaround a permanent fix?

No. Setting TcpReceivePacketSize to 0xFF00 only blocks the exploit by capping TCP DNS responses below the overflow threshold. It is a stopgap until you install the July 2020 (or later) cumulative update, and you should remove it after patching so legitimate large responses are not truncated.

Is SIGRed remote code execution or just a denial of service?

It is remote code execution that runs as SYSTEM, and it is wormable, which is why the CVSS score is the maximum 10.0. The public proof-of-concept on Packet Storm only demonstrates a crash (DoS), but the underlying heap overflow is exploitable for full RCE, so treat it as an RCE.

Do I have to take the DNS server offline to patch?

The fix is a cumulative update that requires a reboot, so the host restarts. On a redundant or clustered DNS deployment you can patch and reboot one node at a time so resolution stays available. A standalone DNS server needs a short maintenance window for the reboot.

References

Written by Sai Kiran Pandrala on 2026-05-25. Sourced from the official vendor advisory, the NVD record, and the CISA KEV listing. Always confirm against the vendor advisory before applying changes in production.

Related weaknesses in the same component worth addressing at the same time:

People also ask

Which Windows servers are actually vulnerable to SIGRed?

Only servers with the DNS Server role installed and acting as a recursive resolver, Windows Server 2008 SP2 through 2019, plus Server Core 1903, 1909, and 2004. Servers without the DNS role and all client OSes are not affected. Run Get-WindowsFeature -Name DNS to confirm.

Is the registry workaround a permanent fix?

No. Setting TcpReceivePacketSize to 0xFF00 only blocks the exploit until you install the July 2020 (or later) cumulative update. Remove it after patching so legitimate large DNS responses are not truncated.

Is SIGRed remote code execution or just a denial of service?

It is wormable remote code execution that runs as SYSTEM, which is why the CVSS score is 10.0. The public proof-of-concept only demonstrates a crash, but the underlying heap overflow is exploitable for full RCE.

Do I have to take the DNS server offline to patch?

The cumulative update requires a reboot. On a redundant or clustered DNS deployment you can patch one node at a time so resolution stays available; a standalone DNS server needs a short maintenance window.