August 22, 2026Vulnerability Analysis

CVE-2026-62878: Wormable Windows DNS Server RCE — What It Is & How to Fix It

Executive Summary

CVE-2026-62878 is a critical, wormable stack-based buffer overflow in the Windows DNS Server service that allows an unauthenticated attacker to execute arbitrary code remotely — with no user interaction required. Disclosed by Microsoft on August 11, 2026 as part of Patch Tuesday, the vulnerability carries a CVSS score of 9.8 and poses an outsized threat to domain controllers that co-host DNS. Patches are available and should be applied immediately, with internet-facing and domain controller-cohosted DNS servers prioritized first.

1. What Is This Vulnerability?

CVE-2026-62878 is a stack-based buffer overflow in the Windows DNS Server service (dns.exe). When the DNS service processes certain network packets, an insufficiently validated input allows an attacker to write beyond the bounds of a stack-allocated buffer. By controlling what is written past that boundary, an attacker can overwrite a function return address or control-flow metadata, ultimately redirecting execution to attacker-supplied shellcode or a ROP chain.

The vulnerability is classified as wormable — meaning that once exploited on a target, the malware payload can automatically scan for and attack other vulnerable DNS servers on the network, spreading without any user interaction. This mirrors the propagation profile of historical wormable DNS exploits, such as those targeting Windows Server 2003's DNS service.

Attack Vector

An unauthenticated attacker sends a specially crafted DNS packet (over UDP/53 or TCP/53) to a vulnerable Windows DNS Server. No credentials, no existing session, and no action on the part of any user is required. The crafted packet triggers the buffer overflow in the DNS parsing path, allowing the attacker to:

Execute arbitrary OS-level commands as SYSTEM or NT AUTHORITY\NETWORK SERVICE
Install backdoors, ransomware, or network implants
Pivot laterally to any Active Directory-connected systems if the DNS server is a domain controller

Because DNS is a UDP service that is routinely open to the internet on resolvers and semi-public infrastructure, the attack surface is very large.

Real-World Impact

No confirmed in-the-wild exploitation has been reported as of August 17, 2026, and no public proof-of-concept exploit code has been released. However, the wormable classification and the prevalence of Windows DNS Servers co-hosted on domain controllers make this a top-priority patch. Historical analogues — MS03-043, MS09-001 — show that wormable Windows services are weaponized rapidly once a functional exploit is developed. The combination of CVSS 9.8 and "no authentication, no user interaction" puts this in the same threat tier as EternalBlue (CVE-2017-0144).

2. Who Is Affected?

The following Microsoft products and versions are confirmed vulnerable:

Product	Status
Windows Server 2025	Vulnerable — patch available
Windows Server 2022	Vulnerable — patch available
Windows Server 2019	Vulnerable — patch available
Windows Server 2016	Vulnerable — patch available
Windows Server 2012 R2	Vulnerable — patch available
Windows Server 2012	Vulnerable — patch available
Windows 10 version 1607	Vulnerable — patch available
Windows 10 version 1809	Vulnerable — patch available

High-risk configurations:

Internet-facing DNS resolvers (recursive resolvers exposed to public internet)
Domain Controllers with DNS role co-hosted (Active Directory-integrated DNS)
DNS servers serving remote sites over WAN

Lower-risk (but still affected):

Isolated lab DNS instances with no external connectivity
DNS servers behind strict perimeter firewall rules blocking inbound UDP/TCP 53

3. How to Detect It (Testing)

Manual Testing Steps

Identify all Windows DNS Servers on your network using Active Directory queries or network scanning.

Determine current patch level on each: check Control Panel → Programs → Installed Updates or run:

Get-HotFix | Where-Object {$_.HotFixID -like "KB*"} | Sort-Object InstalledOn -Descending | Select-Object -First 20

Verify August 2026 Patch Tuesday updates are applied. The relevant KB for DNS Server fixes is included in the cumulative update packages for each OS version. Cross-reference against Microsoft's August 2026 Security Update Guide.
Check DNS service exposure: Determine if UDP/TCP port 53 is reachable from untrusted networks:
```
Test-NetConnection -ComputerName <dns-server-ip> -Port 53
```
If this succeeds from an external/DMZ host, the server is at elevated risk.
Look for anomalous DNS process behavior — unexpected child processes spawned by dns.exe, high CPU on the DNS service, or unusual network connections originating from the DNS server:
```
Get-Process dns | Select-Object Id, CPU, WorkingSet
Get-NetTCPConnection -OwningProcess (Get-Process dns).Id
```

Automated Scanning

Nessus / Tenable: Tenable has released detection content for CVE-2026-62878. Use the following Nessus plugin IDs:

Plugin ID	Description
334611	Windows DNS Server RCE - CVE-2026-62878 (Remote Check)
334607	Windows DNS Patch Audit - August 2026 Cumulative Update
334605	Windows Server 2022 DNS Service Missing Patch
334604	Windows Server 2019 DNS Service Missing Patch
334618	Windows Server 2025 DNS Service Missing Patch
334606	Windows Server 2016 DNS Service Missing Patch

Run a credentialed scan against all Windows Servers with the DNS Server role enabled. Filter results for plugin family "Windows" + CVE "CVE-2026-62878".

Qualys: Run a PC (Policy Compliance) scan with QID filters for August 2026 Patch Tuesday, or search the Knowledgebase for CVE-2026-62878.

PowerShell-based inventory (no scanner required):

# Run on each target or push via GPO/Invoke-Command
$server = $env:COMPUTERNAME
$dnsInstalled = (Get-WindowsFeature DNS).InstallState -eq "Installed"
$patchApplied = Get-HotFix | Where-Object {$_.Description -eq "Security Update"} |
                Where-Object {$_.InstalledOn -gt (Get-Date "2026-08-10")}

[PSCustomObject]@{
    Server       = $server
    DNS_Installed = $dnsInstalled
    AugPatch_Applied = ($patchApplied.Count -gt 0)
}

Code Review Checklist

If you maintain or fork Windows DNS-adjacent tooling (e.g., custom DNS proxy code):

Audit all memcpy(), strcpy(), sprintf() calls operating on externally-supplied DNS label or record data — ensure destination buffer sizes are checked before write
Verify bounds checking is performed on each DNS label length field (RFC 1035 max label length: 63 bytes, max FQDN: 255 bytes)
Confirm use of safe string functions (strncpy_s, snprintf with explicit size limits) wherever DNS-provided input is manipulated
Review stack canary / shadow stack compiler flags if building custom DNS parsing components

4. How to Fix It (Mitigation)

Step-by-Step Remediation

Apply the August 2026 Patch Tuesday cumulative update for your Windows Server version via Windows Update, WSUS, SCCM/Intune, or direct KB download from the Microsoft Update Catalog. The patch ships as part of the monthly rollup and as a standalone security-only update.
Prioritize patching in this order:
- Domain Controllers co-hosting DNS (highest risk — lateral movement impact)
- Internet-facing DNS resolvers
- Internal recursive DNS servers
- Isolated/lab DNS instances (lowest urgency)
Restart the DNS Server service after patching (a full reboot is recommended for cumulative updates):
```
Restart-Service DNS -Force
```

Validate patch installation:

# Check cumulative update installed after Aug 11, 2026
Get-HotFix | Where-Object {$_.InstalledOn -gt (Get-Date "2026-08-10")} | 
Select-Object HotFixID, Description, InstalledOn

Re-run your vulnerability scanner (Nessus/Qualys) to confirm the CVE no longer appears in results for patched hosts.

Temporary Workaround (If Patching Is Delayed)

Microsoft has not published an official non-patch workaround. However, the following defensive measures reduce exploitability:

Block inbound DNS (UDP/TCP 53) from untrusted networks at the perimeter firewall for any DNS server that does not need to be internet-facing:

# Windows Firewall — block external inbound DNS
netsh advfirewall firewall add rule name="Block External DNS Inbound" 
  protocol=TCP dir=in localport=53 remoteip=!<trusted_ip_ranges> action=block
netsh advfirewall firewall add rule name="Block External DNS Inbound UDP" 
  protocol=UDP dir=in localport=53 remoteip=!<trusted_ip_ranges> action=block

Enable DNS Response Rate Limiting (RRL) to throttle abusive query rates:

Set-DnsServerResponseRateLimiting -Mode Enable -ResponsesPerSec 5 -WindowInSec 5

Separate DNS from Domain Controller roles where possible — running DNS on a dedicated (non-DC) server limits the blast radius if the DNS service is compromised.

Configuration Hardening

Enable DNS Server audit logging to capture anomalous query patterns:

Set-DnsServerDiagnostics -All $true

Enable Windows Defender Credential Guard and LSASS protections on Domain Controllers to slow lateral movement in case DNS is compromised:

# Via registry
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\LSA" -Name "RunAsPPL" -Value 1

5. How to Test the Fix (Validation)

Regression Test Scenarios

Scenario A: Confirm August 2026 cumulative update appears in Get-HotFix output — InstalledOn date should be on or after August 11, 2026.
Scenario B: Re-run Nessus with plugin IDs 334604–334618 — CVE-2026-62878 should no longer appear as a finding on patched hosts.

Scenario C: Confirm DNS service continues to resolve internal and external names correctly after patch:

Resolve-DnsName google.com -Server <dns-server-ip>
Resolve-DnsName <internal-domain> -Server <dns-server-ip>

Scenario D: Confirm Active Directory replication is healthy post-patch on any Domain Controllers that received the update:
```
repadmin /showrepl
dcdiag /test:replications
```

Security Test Cases

Test Case 1: Verify CVE no longer flagged by scanner

Precondition: Apply August 2026 cumulative update + restart DNS service
Steps: Run authenticated Nessus scan targeting DNS server, filter for CVE-2026-62878
Expected Result: No findings for CVE-2026-62878; CVSS 9.8 finding is absent

Test Case 2: Verify DNS service operational integrity

Precondition: Patch applied and DNS service restarted
Steps: Perform standard DNS lookups (A, AAAA, MX, PTR, SRV) from a client
Expected Result: All resolution succeeds without error; no DNS service crashes in Event Log

Test Case 3: Confirm perimeter firewall blocks external DNS if workaround applied

Precondition: Firewall rule added blocking inbound UDP/TCP 53 from untrusted sources
Steps: Attempt DNS query from external host (simulated via test IP outside trusted range)
Expected Result: Query times out; no response from DNS server to untrusted source

Automated Tests

# Patch validation script — run post-deployment
$expectedPatchDate = Get-Date "2026-08-11"
$dnsServers = @("dc01.corp.local", "dc02.corp.local", "dns01.corp.local")

foreach ($server in $dnsServers) {
    $patches = Invoke-Command -ComputerName $server -ScriptBlock {
        Get-HotFix | Where-Object {$_.InstalledOn -gt $using:expectedPatchDate}
    }
    $dnsResolves = Resolve-DnsName "google.com" -Server $server -ErrorAction SilentlyContinue

    [PSCustomObject]@{
        Server          = $server
        AugPatchApplied = ($patches.Count -gt 0)
        DNSOperational  = ($null -ne $dnsResolves)
        PatchCount      = $patches.Count
    }
}

6. Prevention & Hardening

Best Practices

Maintain a monthly Patch Tuesday cadence — critical DNS/RPC vulnerabilities are a recurring category. Use WSUS, SCCM, or Intune to enforce ≤30-day patch SLAs for Critical-rated updates, ≤72-hour SLA for wormable or actively exploited CVEs.
Separate the DNS role from domain controllers where your architecture allows — this reduces the blast radius of a DNS compromise from "full domain takeover" to "DNS infrastructure compromise."
Never expose Windows DNS resolvers directly to the internet without strict ACLs. If you must offer external resolution, front it with a hardened Linux-based resolver (Unbound, BIND 9) and forward to Windows DNS only for internal zones.
Maintain an accurate asset inventory of DNS server roles — many organizations don't know how many Windows Servers have the DNS role enabled, which creates patching blind spots.
Disable DNS Server role on servers that don't need it:
```
Uninstall-WindowsFeature DNS
```

Monitoring & Detection

Enable the following to detect exploitation attempts or post-compromise activity:

Windows Event Log monitoring (forward to SIEM):

Event ID	Log	Meaning
4625	Security	Failed logon — watch for unusual accounts post-DNS compromise
7045	System	New service installed — malware persistence indicator
4688	Security	New process created by `dns.exe` — anomalous child processes
1000/1001	Application	DNS application crash / Windows Error Reporting
150	DNS Server	DNS Server audit event (requires DNS logging enabled)

KQL / Sentinel detection rule (detect unusual child processes of dns.exe):

DeviceProcessEvents
| where InitiatingProcessFileName =~ "dns.exe"
| where FileName !in~ ("dns.exe", "conhost.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

Network monitoring: Alert on inbound connections to port 53 from IP ranges outside your defined DNS client and forwarder lists. Unexpected sources querying your internal DNS servers are worth investigating, especially post-disclosure.