Windows DNS, an unauthenticated 9.8: what turns a bug into a worm is not the bug, it's your network

Take a laptop, sit on your office guest wifi and run an nslookup against your domain controller's IP. If it answers, the rest of this article is about you, and none of Tuesday's 972 patches fixes that.

On 8 September Microsoft shipped the largest batch of patches in its history, and there is no agreement on how many it holds. The Zero Day Initiative counts 972 Microsoft CVEs and 114 Critical; CrowdStrike says 972 and 113; Tenable headlines 964; much of the press says 973 or 974. One of the round-ups explains the spread: "depending on how researchers count external and Chromium bugs, Microsoft fixed between 966 and 997 CVEs in this update". None of those figures tells you what to do on Thursday morning.

The bug everybody is talking about

CVE-2026-69730 is a remote code execution flaw in the Windows DNS Server, Critical, CVSS 9.8, a use-after-free according to Talos's breakdown. An unauthenticated attacker sends a crafted packet to the DNS service and executes code on the machine, with nobody clicking anything. Dustin Childs, of the Zero Day Initiative, dispatched it as "SigRed's spiritual successor", and added: "We haven't seen a global worm in years, but with a DNS flaw acting as the spiritual successor to SigRed, that reality could change fast".

Worth pinning down the scope before panic spreads through the inventory: this is the DNS Server role, the thing that resolves names for everyone else, not the DNS client every Windows ships with. Per the published round-ups, Microsoft lists Windows Server 2012 through 2025 — Server Core included — plus Windows 10 versions 1607 and 1809, with no Windows 11. That detail about the two client versions, which are the LTSB and LTSC branches, we cannot fully explain: if the role only exists on Server, it is not clear why they appear. We pass the list on second-hand — the MSRC advisory renders with JavaScript and we could not read it — and suggest checking it there before fixing your scope.

And it is not one DNS bug. It is several. Of the twenty Childs marks as wormable, three are DNS Server: 69730, 69858 and 72987. Talos additionally lists 69813, 69827 and 77505, all code execution at CVSS 8.1. Anyone going in on Thursday to patch "the DNS bug" is going to find half a dozen.

On your network, "the DNS server" is the domain controller

CrowdStrike's analysis says it plainly: "in most Active Directory (AD) environments, DNS runs on domain controllers themselves rather than on dedicated infrastructure", so "a successful exploit against an AD-integrated DNS server can deliver code execution on a domain controller". And they note the track record: similar DNS service flaws "have historically drawn rapid attention from both ransomware operators and nation-state actors because of this co-location pattern".

In the inventory of a fifty-person company that means the vulnerable machine is the same one holding everybody's passwords. It is also the one nobody wants to reboot: it gets patched last precisely because it hurts most if it does not come back.

The twenty wormable bugs are not one list. They are two

First, the attribution, because it is being misquoted out there: "wormable" is not a Microsoft label. It is Childs's personal count, and he says it in these words: "So where are the wormable bugs, you may ask? Well, quite frankly, there are too many to single out. I count 20 different patches that could all be classified as wormable". In each one, "a remote, unauthenticated attacker could get arbitrary code execution on affected systems with no user interaction".

Those twenty CVEs spread across thirteen components: DHCP Server, Active Directory Domain Services, RMCAST, Message Queuing, RRAS, NFS, DNS Server, SMB client, IP Helper, Netlogon, Internet Connection Sharing, SSTP and Failover Cluster. Several round-ups publish a trimmed version of this list with an "and others" at the end, and that "and others" is exactly where the interesting part lives, because the thirteen components do not behave alike. They split into two groups that call for different work, and this separation is our reading, not the sources'.

Group one: irreducible surface. DNS Server (three CVEs), DHCP Server (two), Netlogon (one) and Active Directory Domain Services (one). Seven of the twenty. These are the services a domain-joined workstation has to be able to reach in order to work: without DNS it resolves nothing, without Netlogon it does not log in, without DHCP it does not even have an address. Segmentation will not save you from the workstation here. Cut port 53 on the controller off from the laptops and you stop having a domain at the first ticket renewal. All you can do with this group is patch fast and control which other segments get there.

Group two: roles somebody installed. RMCAST (three CVEs), Message Queuing (two), Failover Cluster (two), RRAS, NFS, Internet Connection Sharing and SSTP (one each). Eleven of the twenty, more than half. None of these ships active on a freshly installed Windows Server. RMCAST's reliable multicast is needed if somebody set up PGM; NFS exists to talk to Unix or an ESXi datastore; RRAS is routing and VPN; SSTP is a tunnel; Message Queuing is the QueueJumper lesson from 2023, when half the world discovered it had MSMQ installed by a third-party product that dragged it in. These eleven CVEs are only wormable where somebody switched the role on and forgot.

Two are left over that fit neither group, and claiming otherwise would be rounding at the expense of the truth. The SMB client is exploited in reverse: it is not a service the laptop reaches on the controller, it is code on the laptop, and the attacker is the malicious server responding with something crafted to a machine that connected to it. And IP Helper does not fit either: iphlpsvc runs by default on every Windows and manages IPv6 tunnels — Teredo, 6to4, ISATAP — so it is neither an optional role nor a controller service, it is something you already have switched on everywhere without having asked for it.

The practical upshot of the split is that the two halves are managed with different tools. The irreducible one is managed through patching order and through who reaches it from where, because you cannot turn it off. The other is managed by uninstalling, which is free and permanent: a role that is not there does not appear on next year's list. And the question hardly anyone can answer from memory is not which of the 972 patches applies to them, but which of those seven optional roles is switched on, server by server. It is the same idea we wrote about in not old bugs, old classes of bug, applied to the inventory instead of the code.

From which comes the answer to the sentence we have heard most this week: "but we don't publish DNS to the internet". Correct, and it does not save you. An internal worm does not come through the perimeter firewall. It arrives on the laptop of somebody who opened the wrong thing, and that laptop is permitted, by design, to talk to port 53 on the domain controller. The surface that counts here is the one the first machine to fall can see.

What we are not going to tell you: that a worm is coming

SigRed, the reference everybody is reaching for, was CVE-2020-1350: a 10.0 in the Windows DNS Server, July 2020, seventeen years latent in the code, with a registry mitigation for anyone who could not patch in time — TcpReceivePacketSize set to 0xFF00 under the DNS service parameters key, documented in KB4569509. That July, people said exactly what is being said this week. The global worm never came.

As of 9 September, as we write this, CVE-2026-69730 is not in CISA's KEV catalogue and we have found no public proof of concept. What there is, and it would be sly to leave it out of the paragraph where we make a show of caution, is that Microsoft rates it "Exploitation More Likely". That is a prediction, not an observation, but it is the prediction of the people who have seen the code. On the other side of the scale, one of the month's round-ups counts 58 fixes carrying that same label and adds that "we have not seen a correlating spike in active exploits – yet". Nor have we verified whether Microsoft published an alternative mitigation for this one; the round-ups we read do not mention any.

It is also worth looking at what is actually being exploited this month, because it is not the 9.8. It is CVE-2026-81963, in the Windows Update Stack, and CVE-2026-85880, in Advanced Local Procedure Call (ALPC): two elevation of privilege flaws at CVSS 7.8 that need local access and serve to reach SYSTEM after you are already in. On the first, Satnam Narang of Tenable notes it is the first of seven Windows Update Stack elevation flaws since 2022 to be exploited as a zero-day; the second was reported by external researchers, Proofpoint among them. The scary number and the number somebody is using against somebody rarely coincide, and that is what the headline is not enough to decide was about.

So why move on the DNS one? Not because of the worm, but because of the short sentence: unauthenticated code execution on a domain controller.

What we would do this week, in order

1. Check who reaches port 53, from where they should not. Twenty minutes, and it is the one that produces the nasty surprises. Take a laptop on the guest wifi, another on the VPN range and something on the printer or camera VLAN if you have one. You have to test both transports, because they are not interchangeable: Test-NetConnection <DC-IP> -Port 53 checks TCP, which is the path of the SigRed class of flaw — hence its mitigation being a TCP packet size limit — while ordinary queries go over UDP, and that is tested with Resolve-DnsName -Server <DC-IP> example.com or an nslookup pointed at the controller. A firewall can allow UDP and block TCP, so stopping at the first command gives you a negative that means nothing. If the guest wifi resolves against your domain controller, you have your finding for the day.

2. Know which machines have the role, not which ones you think have it. Get-WindowsFeature DNS on each server, or across all of them at once with an Invoke-Command fed by Get-ADComputer -Filter {OperatingSystem -like "*Server*"}. And since you are visiting them all, pull the seven group-two roles on the same pass: NFS, RRAS, SSTP, Message Queuing, Failover Cluster, ICS and RMCAST's multicast. The domain controllers almost always turn up and, with surprising frequency, a member server somebody built for a test in 2019 that is still resolving.

3. Segment what can actually be segmented. You are not going to cut workstations off the controller's DNS, Netlogon or SMB; that part of the surface is irreducible for as long as you run Active Directory. What is entirely surplus is the rest: guests, printers, cameras, building systems, the supplier VPN pool. None of them needs to talk to the domain controller, and they are precisely the segments holding the most machines nobody patches. Removing those sources does not fix the CVE. It reduces the number of places it can be launched from.

4. Patch the controllers first, and with judgement. This is not heterodox: it is what Microsoft has always recommended when a flaw hits the controller, and what hardly anyone does. In Active Directory there is no "secondary" — since Windows 2000 all controllers are equal and what exists are FSMO roles — so the useful sequence is: find where they sit with netdom query fsmo, start with a controller holding none of them, verify with repadmin /replsummary that replication is still clean and that the DNS service answers, and leave the PDC Emulator for last.

And a warning that has to travel with that advice, because otherwise we would be pushing you into a worse problem than the CVE: on a domain controller, restoring the virtual machine snapshot is not a rollback plan. Reverting a controller causes a USN rollback that silently breaks replication, unless the hypervisor supports VM-GenerationID and the conditions for it to work are met. Rolling back a controller means uninstalling the update, or promoting another and demoting the affected one. This is not something to improvise at eleven at night.

The fear of patching the controller is not irrational, incidentally: patches break things, and we wrote it up with names attached when an August patch broke printing in WPF applications. That fear is the mechanism producing the medians we discussed in AI finds the zero-day and you take 43 days. The answer is not to stop patching, it is to have the rollback procedure written down along with who executes it out of hours.

5. Look at what else that same machine carries. In many SMEs the domain controller runs DNS and DHCP, which is two of the thirteen components on the list living on one machine. And if your "two controllers" are two virtual machines on the same host, you do not have two: you have one with two names. Neither gets fixed this week, but both are worth writing down today for when the time comes to decide where the next server goes.

When this is not about you

If you have fifteen laptops, no Windows server, identity in Microsoft 365 and DNS from the ISP router, none of this article is about you. There is no DNS Server role, no domain controller, and the list of twenty does not describe your network because your network requires none of it. Update Windows as you would any month and spend the afternoon on something else.

If instead you have a domain, file servers, printers on the same VLAN as people and a guest wifi nobody has looked at since it went in, this month's work is not reading all 972 advisories. It is an afternoon of inventory and an afternoon of rules. Network and communications work is literally this: looking at who can talk to whom and taking out what has no business being there. And it still pays off in a month with no 9.8 in it.

Note on sources

From the Zero Day Initiative's The September 2026 Security Update Review, written by Dustin Childs, come: the count of 972 Microsoft CVEs and 114 Critical; the verbatim quote about the twenty wormable patches and the line about the remote unauthenticated attacker; the full list of those twenty CVEs with their components, from which we derive the thirteen-component split used in the article (DHCP 69510 and 72979; Active Directory DS 69524; RMCAST 69530, 78449 and 78450; Message Queuing 69579 and 83997; RRAS 69590; NFS ONCRPC XDR 69595; DNS Server 69730, 69858 and 72987; SMB client 72936; IP Helper 72981; Netlogon 72982; ICS 72983; SSTP 73009; Failover Cluster 73010 and 78444); and the description of CVE-2026-69730 with its CVSS 9.8 and the SigRed reference. Grouping those thirteen components into "irreducible surface" and "roles somebody installed", and the reading that the first is managed by patching and the second by uninstalling, are OURS and not from any source cited. Several round-ups publish an abbreviated version of the component list ending in "and others"; we took that short version for the complete one in a first draft, and internal fact-checking corrected it. From Help Net Security's coverage come Childs's quotes on SigRed's spiritual successor and the global worm, the attribution to Satnam Narang (Tenable) that CVE-2026-81963 is the first of seven Windows Update Stack elevation flaws since 2022 exploited as a zero-day, and the involvement of Proofpoint researchers in reporting CVE-2026-85880; we have not verified the full credit list for that CVE, hence "among them". From CrowdStrike's analysis come the alternative count of 972 and 113 Critical and the three sentences on DNS co-location with domain controllers. From the Security Affairs summary comes the line about the 966-to-997 range depending on how external and Chromium bugs are counted, the count of 58 fixes Microsoft labels "more likely to be exploited", and the observation that no correlating spike in active exploitation has been seen. From Cisco Talos's breakdown come the "Exploitation More Likely" rating for CVE-2026-69730, that it is a use-after-free, and the other DNS Server CVEs at CVSS 8.1 (69813, 69827, 69858, 72987 and 77505). The affected version list comes from public round-ups and is NOT verified against the MSRC advisory, which renders with JavaScript and we could not read; the anomaly of Windows 10 1607 and 1809 appearing there we leave declared as something we cannot explain. The SigRed details (CVE-2020-1350, CVSS 10.0, July 2020, seventeen years in the code, TcpReceivePacketSize at 0xFF00, KB4569509) come from Microsoft documentation and the analyses published at the time; QueueJumper is CVE-2023-21554. That as of 9 September 2026 CVE-2026-69730 is not in CISA's KEV catalogue and that we found no public proof of concept is a check we made on that date, not a guarantee. The warning about USN rollback when reverting domain controller snapshots and the behaviour of VM-GenerationID come from Microsoft's Active Directory documentation. Spanish and Catalan quotations are our own translations from the English originals. The commands are standard Windows Server ones and do not replace checking in your own environment. The cover photograph is in the public domain.