9.8 Windows DNS RCE: 3 Triage Checks Before It Repeats SigRed

Triage Checklist for CVE-2026-69730

Microsoft's September Patch Tuesday landed a record-setting pile of roughly 970 new CVEs, and two of them are already being exploited. Buried in that pile is the one I would patch first: CVE-2026-69730, a CVSS 9.8 remote code execution in the Windows DNS Server role. No authentication, no user interaction, one crafted packet to port 53. Zero Day Initiative called it "SigRed's spiritual successor", a nod to the 2020 Windows DNS bug that let researchers walk from a single DNS query to Domain Admin.

I spent this morning pulling the advisory apart for the Windows DNS servers in my home lab, and this post is the triage checklist that came out of it: find every machine running the DNS Server role, read the fixed build numbers correctly, and hunt for crash precursors in the logs.

Check 1: Find Machines Running the DNS Server Role (AD Module + WinRM)

$servers = Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' -Properties OperatingSystem | Select-Object -ExpandProperty DNSHostName
foreach ($s in $servers) {
    $hasDns = Invoke-Command -ComputerName $s -ErrorAction SilentlyContinue -ScriptBlock { (Get-WindowsFeature -Name DNS).Installed }
    "{0} -> DNS Server role: {1}" -f $s, $hasDns
}

Example output from my lab:

dc01.lab.local -> DNS Server role: True
dc02.lab.local -> DNS Server role: True
file01.lab.local -> DNS Server role: False

What Exactly Did September Patch Tuesday Ship for DNS?

Six DNS remote code execution fixes, headlined by CVE-2026-69730 at 9.8:

CVE	Component	Severity
CVE-2026-69730	Windows DNS Server	9.8
CVE-2026-69858	Windows DNS Server	8.1
CVE-2026-69813	Windows DNS Server	8.1
CVE-2026-69827	Windows DNS Server	8.1
CVE-2026-72987	Windows DNS	8.1
CVE-2026-77505	Windows DNS Server	8.1

ZDI counted 20 wormable-class patches in the whole release, and DNS fills six of the slots. An integer-overflow DoS in Windows DNS (CVE-2026-69631, 7.5, flagged automatable) surfaced in the same 48-hour DNS feed.

One oddity worth an hour of your time: CVE-2026-72987 is listed as "Windows DNS" while the rest say "Windows DNS Server", so before treating it as a server-only problem, check which component it actually patches.

Why Is a DNS Parser Bug Different from Every Other RCE?

Reachability. DNS is designed to accept unauthenticated packets from strangers, which makes "unauthenticated" a feature the attacker does not have to work around. And in most Active Directory shops the DNS Server role is co-hosted on domain controllers, so the box answering queries on port 53 is also the box holding your entire identity database.

Contrast that with the two bugs being actively exploited this month: both are elevation of privilege flaws that need a foothold on the machine first. CVE-2026-69730 needs only a network path. That is the profile ZDI's Dustin Childs warned about when he described it as creating "severe, self-propagating contagion risk across enterprise networks".

What Does "More Likely" Mean When Nothing Is in KEV?

As of this writing there is no public proof of concept, no KEV entry, and Microsoft rates exploitation "More Likely". Those facts can coexist. KEV lags real exploitation, exploit probability models start cold on fresh CVEs, and vendor exploitability ratings are predictions. I treat "More Likely" plus a wormable profile as a planning input, not reassurance.

What Does Use-After-Free Actually Do Inside a DNS Server?

CVE-2026-69730 is CWE-416. The skeleton of the bug class is small enough to hold in your head:

// The classic CWE-416 shape, stripped to the skeleton
char *name = malloc(len);           // 1. buffer allocated for a parsed name
parse_compressed_name(name, pkt);   // 2. attacker-controlled packet parsed into it
free(name);                         // 3. buffer released
// attacker forces a new allocation that reuses the same heap slot
lookup_offset(name);                // 4. stale pointer now reads attacker bytes

After step 3 the allocator owns that memory. If the service keeps using the old pointer, whatever lands in the freed slot is what the stale pointer reads, and if that data flows into a function pointer or an object with a vtable, the crash becomes control flow. In a service running as SYSTEM on a domain controller, control flow is Domain Admin.

Why Compressed Names Keep Biting DNS Parsers

DNS name compression lets a response point back into earlier parts of the packet instead of repeating a name. Parsers have to chase those offsets with bounded checks, and 25 years of DNS CVEs suggest that is easy to get wrong. SigRed (CVE-2020-1350) was exactly this neighborhood: a crafted SIG record response expanding past 64KB overflowed dns.exe, and Check Point turned it into Domain Admin through the DNS service's own LDAP call.

I do not know whether the 2026 bug lives in the compression path, and I will not pretend otherwise. Microsoft's description is one sentence and NVD still shows "Awaiting Analysis".

Which Servers Should You Patch First (and How Do You Read the Builds)?

Compare the running build against the fixed builds NVD lists:

• Server 2025 at 10.0.26100.33438
• Server 2022 at 10.0.20348.5622
• Server 2019 at 10.0.17763.9245
• Server 2016 at 10.0.14393.9512
• Server 2012 R2 at 6.3.9600.23397
• Server 2012 at 6.2.9200.26349

Check 2: Read the Running OS Build

Invoke-Command -ComputerName dc01.lab.local -ScriptBlock { [System.Environment]::OSVersion.Version.ToString() }
# Server 2022 needs 10.0.20348.5622 or higher

My order: anything internet-facing goes first (that number should be zero; if it is not, it is priority zero), then DC-cohosted DNS, then internal recursive resolvers, then lab boxes. Prioritizing by reachability is the same logic I used when two CVSS 9.8 agent sandbox CVEs landed the same day: what an attacker can touch without a foothold goes first.

Reading the NVD Build Numbers

The lessThan values are exclusive ceilings: at or above the listed build you are patched. Windows Server 2012 and 2012 R2 appear in the list because they remain covered by Extended Security Updates until October 13, 2026, so "my 2012 DC is out of support" is not a reason it missed this fix.

Can You Hunt for Exploit Attempts Without a Signature?

A memory-corruption exploit usually crashes the target a few times before it runs reliably. You can set a cheap tripwire on that behavior:

Check 3: Tripwire for dns.exe Crashes Reported by Windows Error Reporting

Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Application Error'; StartTime = (Get-Date).AddDays(-3) } -ErrorAction SilentlyContinue | Where-Object { $_.Message -match 'dns\.exe' } | Select-Object TimeCreated, MachineName

This is a tripwire, not a wall. A clean log proves nothing on its own, and a working exploit may never crash anything. Until public detections exist, though, "did dns.exe die on this box" is one of the only signals you control.

Is "Patch DNS First" Even the Right Long-Term Answer?

Here is the argument I actually want to have.

Camp one patches every month and accepts the treadmill.

Camp two says a bug class that keeps landing (SigRed in 2020, a six-CVE cluster in 2026) is evidence the architecture is wrong: stop co-hosting DNS on domain controllers, keep Windows DNS off the internet permanently, and consider moving recursion to a service with a different memory-safety story.

My lean: both, on different clocks. Patch this week, re-architect this quarter.

The honest counterpoint to my own position: separating DNS from DCs trades a known risk for new complexity, and "internal only" is a claim rather than a control, something I keep running into, from network-reachable session state in MCP to the way privileged CI tokens get reused. Co-hosting bundles two privileged identities into one box, and bundling is its own vulnerability class.

Takeaways

• Patch CVE-2026-69730 on every machine with the DNS Server role; five more 8.1 DNS RCEs shipped the same day.
• 9.8 plus unauthenticated plus zero interaction is the wormable profile; treat "More Likely" as a planning input, not reassurance.
• Verify by build number from NVD, and hunt dns.exe crashes while signatures catch up.

So, the question for the comments: does a 9.8 wormable DNS RCE outrank two actively exploited local privilege escalations in your patch order? This month mine does. I would genuinely like to read the case for the other side.