CVE-2026-62820

Windows DNS Server is the service that translates names (like website addresses) into IP addresses so computers can find where to connect. This vulnerability is a timing bug: if an attacker sends the right network traffic at the right moment, they may be able to run their own code on the DNS server even without a login. If that happens, the attacker can often fully control the machine and tamper with files and data.

This matters if your business runs Windows DNS Server on Windows 10 or Windows Server 2016/2019/2022/2025. Because it is reachable in default configurations and needs no authentication or user interaction, systems exposed to untrusted networks are at higher risk. The core gate for exploitation is network reachability to the DNS server; no login is required, but the timing condition is described as high-complexity to successfully trigger.

This is RED urgency because it can allow remote attackers to gain complete control of a DNS server without authentication or user action. Even though successful triggering is described as high complexity, the issue is reachable in default configurations and the patch is available for all affected Windows versions, so you should act now.

1. Identify exposure

   • Determine which machines run the Windows DNS role/service for your organization (and which ones are reachable from other networks, including any remote/edge connectivity).
   • Confirm whether any of these are in use: Windows 10, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server 2025.

2. Check patch level (what to look for)

   • For each affected OS, verify the build/version is at or beyond the fixed versions provided:
     • Windows 10: fixed in 10.0.14393.9418 and 10.0.17763.9121
     • Windows Server 2016: fixed in 10.0.14393.9418
     • Windows Server 2019: fixed in 10.0.17763.9121
     • Windows Server 2022: fixed in 10.0.20348.5499
     • Windows Server 2025: fixed in 10.0.26100.33296

3. Upgrade/patch procedure

   • Apply the fixed versions to each server/workstation that provides DNS.
   • After updating, validate DNS functionality (name resolution for internal clients and any dependent services).

4. Temporary containment if patching is delayed

   • Restrict network access to the DNS service to only the networks/subnets that require it (for example, internal LANs, VPN networks, and approved management subnets).
   • Avoid exposing DNS to the open internet or other untrusted networks until patched.

5. What to monitor after patching

   • Watch for unusual DNS-related network activity around the DNS server (unexpected remote traffic patterns).
   • Check for signs of compromise on the DNS server (unexpected processes, changes to system files), especially if the server is broadly reachable.

6. CISA KEV timing note

   • This CVE is not listed in CISA KEV, and no clear dated real-world incident report was provided in the supplied findings; however, the vendor patch is available and the exposure conditions include default reachability, so patching remains the primary action.

Severity is high: the impact described includes complete control of the compromised computer (read/modify/delete files), with a network attack vector, no authentication required, and no user interaction required. The underlying weakness is CWE-362, a race condition: concurrent handling of shared resources in Windows DNS can be improperly synchronized, allowing an attacker to time requests to reach a state that results in remote code execution.

Findings indicate the issue is reachable in default configuration, which increases practical exposure. Successful triggering is described as high complexity, and no public exploit code was reported in the supplied findings; however, the Patch/PULSE information notes actor interest (Lazarus group) and that a patch is available for all affected Windows releases.

KEV: not listed in CISA KEV. Exploitation: no clear dated press claim and no incidents reported in the supplied findings. EPSS: a prediction was provided (0.5%, flat trend), but exploitation-confirmation sources were not present in the supplied findings; therefore, follow the RED remediation priority because the weakness is reachable by network and fixes exist.