CVE-2026-62878: The Wormable Windows DNS Server Bug You Need to Patch Now

A single network packet, sent to a Windows DNS server that’s never authenticated the sender and never asked a human to click anything, is enough to run arbitrary code. That’s CVE-2026-62878, disclosed in Microsoft’s August 2026 Patch Tuesday with a CVSS score of 9.8, and it’s the kind of bug security researchers reach for the word “wormable” to describe, not because it’s already spreading, but because it has every property a self-propagating exploit needs.

What’s actually broken

CVE-2026-62878 is a stack-based buffer overflow in Windows DNS Server. In plain terms: the DNS service allocates a fixed-size chunk of memory on the stack to hold part of an incoming request, and a specially crafted packet can supply more data than that chunk was sized for, overwriting adjacent memory with attacker-controlled content. Get that overwrite right, and you don’t just crash the service, you redirect execution to code the attacker supplied.

What makes this bug specifically dangerous rather than merely serious is the combination of three properties, all present at once:

• Remote. The attacker doesn’t need any existing foothold on the network, just the ability to send a packet to the DNS server.
• Unauthenticated. No credentials, no valid session, nothing to steal or guess first.
• Zero interaction. No user has to open anything, click anything, or be tricked into anything. The DNS server processes the malicious packet as part of its normal job.

That combination is the same one security researchers point to when they call a bug wormable: a single compromised or attacker-controlled host on a network could, in principle, scan for other exposed DNS servers and propagate the exploit automatically, server to server, without a human anywhere in the loop after the first infection.

Wormable doesn’t mean it’s already spreading

It’s worth being precise here, because the word “wormable” gets used loosely. As of this writing, there’s no confirmed report of CVE-2026-62878 being exploited in the wild. Microsoft’s disclosure describes the vulnerability’s characteristics and its exploitability rating, which is what earns it the wormable label, but exploitability rating and observed exploitation are different things, and this one is currently the former.

That’s exactly the window where patching actually matters most, not after exploitation starts. The historical pattern for critical, unauthenticated, no-interaction Windows bugs is that once public proof-of-concept code appears, and it usually does within days to a couple of weeks of disclosure for a bug this severe, the gap between “researchers have a working exploit” and “opportunistic scanning starts hitting every exposed server on the internet” can be extremely short. Patching before that window opens is the entire point of prioritizing a CVSS 9.8 disclosure over routine monthly patching cadence.

Where this fits in a very dense Patch Tuesday

CVE-2026-62878 didn’t land alone. The same August 2026 update batch included two other bugs rated CVSS 9.8:

CVE	Component	Type
CVE-2026-62878	Windows DNS Server	Stack-based buffer overflow, RCE
CVE-2026-62815	Microsoft QUIC	Use-after-free, RCE
CVE-2026-62893	Windows Deployment Services (TFTP)	RCE via crafted packets

All three share the unauthenticated, no-interaction profile. That’s an unusually dense cluster of wormable-class bugs in a single update, and it’s a reasonable prompt to check your patch rollout priority queue rather than treating this as one bug among the routine monthly batch. If your organization tracks actively exploited vulnerabilities separately from routine severity scoring, the same KEV-first triage logic we’ve written about for CVE-2026-68820 applies here in reverse: this one isn’t confirmed exploited yet, so it’s a race against the clock rather than a fire already burning, and the right response is to patch before it becomes the former.

What to actually do

1. Identify every Windows Server instance running the DNS Server role. This is a DNS-specific bug, not a general Windows Server flaw, so scope your patch priority to hosts actually running that role first.
2. Apply the August 2026 cumulative update to those hosts as a priority, ahead of the routine monthly rollout if your patch cadence normally staggers by weeks.
3. If immediate patching isn’t possible, restrict network access to DNS servers to known secondary DNS servers and management hosts only, rather than leaving query ports reachable broadly. Treat this as a stopgap, not a fix.
4. Watch for proof-of-concept code. Once a working exploit becomes public, the priority for any still-unpatched DNS server changes from “should patch soon” to “patch today.” Security mailing lists and CVE trackers typically flag this transition quickly.

If your team runs a formal vulnerability management process and wants a second opinion on how a bug like this should be prioritized against everything else in your patch queue, that kind of review is part of the infrastructure and security work our team does for clients running Windows Server environments at scale.

The takeaway

A CVSS 9.8 rating on a remote, unauthenticated, zero-interaction bug in a service most networks expose broadly by design is as close to a worst-case combination as vulnerability scoring gets. The fact that it hasn’t been exploited yet is good news with an expiration date, not a reason to deprioritize it. Patch the DNS Server role first, and treat the absence of confirmed exploitation as the reason to move fast, not the reason to wait.