On Tuesday 11 August Microsoft published CVE-2026-62878: a stack-based buffer overflow in Windows DNS scoring 9.8 out of 10. No credentials, nobody has to click anything, just a packet over the network. What makes this bulletin different from the other three hundred-odd released the same day isn't the score: it's which machine runs that service in most of the companies we visit.
It's the domain controller. The same one that validates passwords, hands out group policies and holds the shared folder. And that's why it hasn't been rebooted in months, sometimes years.
What the bulletin says, plainly
The data comes from Microsoft's own Security Response Center, checked on 13 August:
- ›Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base score 9.8, critical severity, CWE-121 (stack-based buffer overflow). - ›The bulletin's FAQ puts it like this: "an unauthenticated attacker could exploit this vulnerability by sending a specially crafted packet to an affected service over the network. No authentication or user interaction is required."
- ›It wasn't publicly disclosed, there's no detected exploitation, and Microsoft's assessment is "Exploitation Less Likely". The vector says as much in its temporal half:
E:U, exploit code unproven, which brings the temporal score down to 8.5. Worth saying early: this isn't a fire today. - ›The affected products list has sixteen entries: Windows Server 2016, 2019, 2022 and 2025 (with and without a GUI), Windows 10 versions 1607 and 1809, and Windows Server 2012 and 2012 R2, which appear in the bulletin under the ESU family. For those two the patch exists — rollups
KB5120386andKB5120385— but it only reaches you if you pay for extended support, the toll that keeps going up. - ›Every supported version has its cumulative update:
KB5120233for Windows Server 2025,KB5120242for 2022,KB5120238for 2019 andKB5120418for 2016. In the "reboot required" column, all sixteen entries say yes.
The Zero Day Initiative, which publishes its review every month, summed it up with a line that gives you the measure of it: "a good ol' fashioned stack-based buffer overflow that ends up wormable." Wormable means that if somebody works out a reliable way to trigger it, it hops from one machine to the next without anyone opening an attachment.
The person who never takes holidays
We've all worked somewhere with that one person who never took holidays. Not out of dedication: because nobody else knew how to close the month, or sign off on that thing, or touch the old program. People said it as a compliment — "we couldn't manage without them" — while it described a failure of the organisation. The proof arrived the day that person got ill on an ordinary Tuesday and the whole department stopped.
We do exactly the same thing with servers, except that we call the dependency consolidation. One machine acting as DNS, domain controller, file server, print server and, if the day allows, the line-of-business application server too. It works. It works for years. And the day you have to reboot it, no hour in the calendar turns out to be a good one.
DNS living on the domain controller is nobody's slip-up
Let's not hand out blame where it doesn't belong. Active Directory needs DNS: clients locate domain controllers by querying SRV records, and the controllers themselves talk to each other by name. And the Windows Server promotion wizard ships with the box already ticked. Microsoft's documentation says so in as many words: "when you create a forest, the Domain Name System (DNS) server option is selected by default", and further down, "we recommend that all domain controllers provide DNS and global catalog services for high availability in distributed environments. For this reason, these options are enabled by default."
Read the whole sentence, because the half that gets quoted less is the one that matters: the recommendation is that all domain controllers provide DNS — plural — and the stated reason is high availability. The design Microsoft describes is fine. The trouble shows up when things stop halfway: the box gets ticked and the second controller never happens. At that point the box stops delivering high availability and starts concentrating two critical jobs on one box.
To gauge how tightly the two roles are wound together, it's worth reading Microsoft's table on what happens if you force the removal of a controller that also serves DNS: the Active Directory-integrated zone data that server held goes with it, and the action the same table tells you to take beforehand is to review the DNS configuration of every computer pointing at that IP address. An ordinary name service doesn't make you revisit the whole estate when one machine leaves.
What stops while that machine boots
This is where the maintenance window stops being a formality. Workstations find out who to ask for a Kerberos ticket by looking up SRV records in the domain's DNS; if the only server answering them is booting, what degrades isn't "browsing": it's new logons, group policy processing, mapped drives, print queues and any application that authenticates against the directory. Machines already switched on hold out for a while thanks to caches and tickets that haven't expired yet, and that's exactly what makes the problem look small until it isn't.
And rebooting a controller doesn't take as long as a reboot takes. It takes the system boot, plus the directory services starting, plus the SYSVOL check, plus however long a client keeps insisting on the server that went away. Which is why the conversation with the business shouldn't be about "five minutes": it should be about what time of day the office can go without names.
The one actually being exploited scores 7.0
The same batch included CVE-2026-68820: a use-after-free in the Ancillary Function Driver for WinSock (afd.sys) that leads to SYSTEM. Base 7.0, "important" severity, and high attack complexity because, per Microsoft's own FAQ, "successful exploitation of this vulnerability requires an attacker to win a race condition". It's the only one in the batch flagged as "Exploitation Detected"; according to BleepingComputer it has been used to deploy a new version of the FudModule rootkit, and the research is credited to Moshe Marelus and David Driker of Check Point.
The Zero Day Initiative aims a jab at it that's worth quoting in full, because it explains why these entries need reading with both hands: "Microsoft lists the Exploit Code Maturity in the CVSS as 'Unproven' but calls this out as actively exploited." Two labels in the same bulletin contradicting each other, and whoever has to decide this week lives with that contradiction.
The review we ask for before touching a domain controller
Six checks, all boring, all before the window:
- 1Count the controllers that survive independently. Two VMs on the same host and the same storage add up to one. And run
repadmin /replsummaryanddcdiag /test:replicationsbefore touching anything: replication that broke weeks ago always gets discovered at the worst possible moment. - 2Look at who your clients resolve against. The DHCP scope should hand out two DNS servers and both should answer. It's the most common failure we come across: two controllers built and the scope handing out a single IP, because the second one arrived later and nobody went back to DHCP.
- 3Have the console before you need it. Out-of-band access — iDRAC, iLO or the hypervisor console — tested before the reboot, and checked that this console doesn't authenticate against the domain you're about to leave without DNS. It's the same circular dependency we described with the backup server: the rescue tool hanging off the thing you want to rescue.
- 4One at a time, with a gap in between. Never both controllers in the same window, however short the reboot and however strong the temptation. Between the first and the second, verify replication again.
- 5Keep a system state backup and make sure someone can restore it. Rolling a controller backwards has its own rules: even though VM-GenerationID has prevented the worst case of USN rollback since Windows Server 2012 where the hypervisor exposes it, that's the vendor's safety net rather than your procedure. A VM snapshot to back out of a patch that looks wrong, yes; a DC recovery plan, no.
- 6When you're done, check the build number. Compare it with the one Microsoft publishes for that KB (
winveror[System.Environment]::OSVersion.Version) rather than trustingGet-HotFixalone, which misses entries when cumulative updates are involved. Then the DNS service running,dcdiag /test:dnsand a real lookup from a workstation.
One indicator is worth more than any dashboard: how long since that server was last rebooted. If uptime is measured in years, what you're measuring is a maintenance window postponed until it turned into a fear. And fears of this kind go away the day somebody builds the second controller and the first one stops being irreplaceable.
When NOT to reboot anything tonight
Three warnings that go against the industry reflex, ours included:
- ✗If you have a single controller and no out-of-band console, don't reboot it at nine in the morning "to see what happens". There's no known exploitation and Microsoft rates exploitation as less likely: you have room to plan it properly this week.
- ✗We don't build a second controller if it's going to live on the same host and the same disk as the first. That's the same risk with twice the maintenance, and we won't sell it to you as redundancy. It's the same thing we say about high availability: if the design doesn't survive the question "what if that host dies?", the label is wrong.
- ✗And be careful with "my DNS is internal". Internal doesn't mean unreachable: that packet can come from any laptop in the office carrying something it shouldn't, and that's precisely the scenario where a network-reachable, unauthenticated flaw is convenient for somebody who already got in another way.
There's another Patch Tuesday on 8 September
The list of machines needing a reboot will look much like this month's, and October's will too. August's patch goes in overnight; the inventory of servers that can only be rebooted with management's permission drags on for years. There are twenty-six days between now and 8 September, which is plenty of time to build a second domain controller on separate hardware, hand out both in DHCP, and strip that machine of its irreplaceable status.
Sources (checked on 13 August 2026): CVE-2026-62878 and CVE-2026-68820 entries with vector, exploitability assessment, FAQ, affected products, KB articles and reboot requirement — Microsoft MSRC; the August 2026 review with the 398 CVE count, the wormable overflow quote and the contradiction between labels — Zero Day Initiative; afd.sys exploitation, the FudModule rootkit and research credits — BleepingComputer; options ticked by default when promoting a controller and forced-removal warnings — Microsoft Learn.
How long since your domain controller was last rebooted?
The IT maintenance we do starts well before the patch: with a window where it can be applied without stopping the office, and with somebody on the other end of the phone if the server takes its time coming back. That second part is 24x7 support. If you have a single server doing everything, we'll tell you straight, and we'll also tell you whether you can live with it for another year.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN