CVE-2020-1350 (SIGRed) is a critical remote code execution flaw in the Windows DNS Server role that lets an attacker run code as Local System through a crafted DNS response. Fix it by installing the July 2020 security update, or any later one, on every DNS server. If patching must wait, set TcpReceivePacketSize to 0xFF00 and restart the DNS service.
What the scanner is actually detecting
Tenable publishes two Nessus plugins for this CVE, and they work very differently:
| Plugin | Finding title | Family | How it checks |
|---|---|---|---|
| 138600 | Windows DNS Server RCE (CVE-2020-1350) | Windows : Microsoft Bulletins | Local, credentialed. Checks for the July 2020 security updates and for Microsoft’s registry mitigation. |
| 138554 | Microsoft DNS Server Remote Code Execution (SIGRed) | DNS | Remote, unauthenticated. Compares the version the DNS server reports about itself against known vulnerable versions. |
Plugin 138600 is the authoritative one, because it reads the host’s patch level and registry directly over SMB. Plugin 138554 only sees what the DNS service answers on the network, and Tenable notes that the full Microsoft DNS server version is only returned when the server’s EnableVersionQuery setting is 1. Treat a 138554 hit without a matching 138600 result as a prompt to run a credentialed scan, not as proof either way.
The bug itself sits in the Windows DNS Server implementation (dns.exe). According to Check Point, which discovered it, the SIG record parser mishandles an oversized response delivered over TCP, causing a heap overflow. Microsoft states the Windows DNS client is not affected and that only Windows servers configured as DNS servers are at risk.
Real-world risk
Microsoft rates CVE-2020-1350 at CVSS 10.0 and calls it wormable, meaning it could spread between vulnerable servers without user interaction. When the fix shipped on July 14, 2020, Microsoft said it was not known to be used in active attacks. CISA added it to the Known Exploited Vulnerabilities catalog in November 2021 (see our explainer on the CISA KEV catalog for what that listing means for patch deadlines), and Tenable lists a commercial exploit for it.
Stated plainly: the attacker needs the vulnerable DNS server to look up a name in a domain they control, then answers with a malicious record. Any client that can ask the server to resolve a name can start that chain, which is why Microsoft says internal, non-public DNS servers are affected too. Because the Windows DNS role usually runs on domain controllers, successful code execution as Local System is a direct path to domain compromise, and even a failed attempt can crash the DNS service, taking name resolution down for every client that depends on that server.
The other honest point: this was fixed in July 2020, so a server that is current on updates is not vulnerable. A live finding in 2026 almost always means the host has missed years of updates or runs an out-of-support Windows Server version, and that gap is a bigger problem than this single CVE.
How to confirm it on the host
From an elevated PowerShell prompt on the flagged server, first confirm the DNS Server role is actually present and running:
Get-WindowsFeature -Name DNS
Get-Service -Name DNSThen check the patch level. On Windows Server 2016 and 2019 the build number and update revision (UBR) are the quickest signal:
Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion' |
Select-Object ProductName, CurrentBuild, UBR
Get-HotFix | Sort-Object InstalledOn -Descending |
Select-Object -First 10 HotFixID, InstalledOnFinally, check whether the workaround is already in place:
reg query "HKLMSYSTEMCurrentControlSetServicesDNSParameters" /v TcpReceivePacketSizeThe July 2020 updates that fix the flaw, per Microsoft’s Security Update Guide:
| Windows Server version | July 2020 update |
|---|---|
| 2019 | KB4558998 (OS build 17763.1339) |
| 2016 | KB4565511 (OS build 14393.3808) |
| version 1903 and 1909 | KB4565483 |
| version 2004 | KB4565503 |
| 2012 R2 | KB4565541 (Monthly Rollup) or KB4565540 (Security Only) |
| 2012 | KB4565537 (Monthly Rollup) or KB4565535 (Security Only) |
| 2008 R2 SP1 | KB4565524 (Monthly Rollup) or KB4565539 (Security Only) |
| 2008 SP2 | KB4565536 (Monthly Rollup) or KB4565529 (Security Only) |
A build or rollup newer than the one listed also contains the fix. The exception is Security Only packages on 2008 through 2012 R2: they are not cumulative, so a server patched only with Security Only updates needs the July 2020 package itself installed.
How to fix it
The real fix: install the update
Deploy the latest cumulative update or Monthly Rollup for the OS through WSUS, Configuration Manager or the Microsoft Update Catalog, then reboot during a maintenance window. On Windows Server 2008 and 2008 R2 these rollups install only on servers enrolled in Extended Security Updates, so an unlicensed server will fail the install; the durable answer there is moving the DNS role to a supported Windows Server version, which is also a baseline item in our Windows Server hardening checklist.
If you run several domain controllers with DNS, patch and reboot them one at a time so clients can fail over to the remaining servers.
Temporary workaround: limit TCP response size
If a server cannot be patched right away, Microsoft’s KB4569509 workaround caps the size of inbound TCP DNS responses the server will accept, which blocks the oversized record the exploit needs. The value lives under:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters
Value name: TcpReceivePacketSize
Type: DWORD
Data: 0xFF00 (65280 decimal)From an elevated command prompt (not PowerShell 5.1, which does not accept &&):
reg add "HKLMSYSTEMCurrentControlSetServicesDNSParameters" /v TcpReceivePacketSize /t REG_DWORD /d 65280 /f
net stop dns && net start dnsOr in PowerShell:
New-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetServicesDNSParameters' `
-Name TcpReceivePacketSize -PropertyType DWord -Value 0xFF00 -Force
Restart-Service -Name DNSThe DNS service restart is mandatory; the setting does nothing until the service restarts. A full server reboot is not needed. Use exactly 0xFF00, the value Microsoft documents and the one Tenable’s plugin looks for.
Deploying the workaround with Group Policy
For many servers, create a Group Policy Preferences registry item under Computer Configuration > Preferences > Windows Settings > Registry with action Update, hive HKEY_LOCAL_MACHINE, key path SYSTEMCurrentControlSetServicesDNSParameters, value name TcpReceivePacketSize, type REG_DWORD and data FF00 (hexadecimal). Group Policy writes the value but does not restart the DNS service, so schedule that restart separately on each server.
How to verify the fix and rescan
- Re-run the build, UBR and Get-HotFix checks after the reboot and confirm the server is at or above the build or KB listed above.
- If you used the workaround, confirm reg query returns 0xff00 and that Get-Service -Name DNS shows the service running.
- Test name resolution from a client, for example Resolve-DnsName www.microsoft.com -Server <dns-server-ip>.
- Rescan with a credentialed Nessus policy so plugin 138600 can read the registry and patch level. A scan without working Windows credentials cannot run the local check at all.
What can break and how to roll back
The fix ships inside a normal monthly update, so it carries the usual risks of any cumulative update or rollup: stage it on one DNS server before the rest. Uninstalling it to fix an unrelated problem reopens the vulnerability, so apply the workaround first if you ever have to roll a DNS server back.
The workaround has a documented trade-off. Microsoft says TCP DNS responses larger than 0xFF00 bytes are dropped without error. Standard deployments and recursive queries are unlikely to hit that limit, but unusual setups could see unexplained lookup failures. Microsoft suggests enabling DNS diagnostic logging and capturing a representative sample of your traffic if you are unsure.
Microsoft also recommends removing the value once the update is installed, so it cannot cause problems later. Rollback is the same step:
reg delete "HKLMSYSTEMCurrentControlSetServicesDNSParameters" /v TcpReceivePacketSize /f
Restart-Service -Name DNSDelete only that value. Every other entry under the Parameters key belongs to the DNS server configuration and must stay. If you deployed it through Group Policy Preferences, remove or retarget that item first, or it will write the value back.
Common false positive reasons
- Remote version guess. Plugin 138554 depends on the version string the DNS server returns. When version queries are limited or disabled, the result is less reliable. Confirm with the credentialed plugin 138600.
- Workaround applied, remote plugin still firing. The remote check cannot see the registry, so 138554 keeps reporting until the server is updated. That is expected, not a scanner fault.
- Pending reboot. The update installed but the server has not restarted, so the patched files may not be in use yet. Reboot, then rescan.
- No DNS role. Microsoft says only servers configured as DNS servers are affected. If Get-WindowsFeature -Name DNS shows the role is not installed, read the plugin output to see what triggered it before accepting or disputing the finding.
- Stale results. The server was fixed after the scan that raised the finding. Rescan before escalating.
FAQ
Is the Windows DNS client affected by SIGRed?
No. Microsoft states only the Windows DNS Server implementation is affected. Workstations and member servers without the DNS Server role are not vulnerable.
Do I need both the update and the registry workaround?
No. Microsoft says the update alone resolves the vulnerability. The workaround is a stopgap for servers you cannot patch yet, and it should be removed after patching.
Does the workaround require a reboot?
No server reboot, but the DNS Server service must be restarted for the value to take effect. The security update itself needs a normal reboot.
Are Windows Server 2022 and later affected?
They are not in Microsoft’s list of affected products, which runs from Windows Server 2008 through version 2004. Later releases shipped after the July 2020 fix.
Tracking this finding across many hosts
On an estate with many domain controllers, the hard part is proving every DNS server got the update and that temporary workarounds were removed afterwards. If you use SITEY, you can upload the .nessus export to track plugin 138600 per host, have AI draft a host-specific patch or registry script that runs only after human approval through SITEY agents on Windows endpoints, and use per-finding Nessus retest to confirm closure.