CVE-2026-69730: An Unauthenticated 9.8 in the Service Every Domain Controller Runs

Microsoft's September 8, 2026 Patch Tuesday shipped fixes for 997 CVEs — a number that on its own has stopped meaning much, because every month is now a four-digit month. But one of them is worth pulling out of the pile: CVE-2026-69730, a use-after-free in Windows DNS Server that lets an unauthenticated remote attacker execute code by sending a single crafted packet. CVSS 9.8. No login, no click, no attachment. The packet arrives and the code runs.

We're writing about this one specifically because of where it lands, not just how bad it is on paper.

What the bug actually is

CVE-2026-69730 is a use-after-free: a piece of memory gets freed, something else still holds a reference to it, and an attacker who can control the timing and the packet contents can get that stale reference to point at attacker-controlled data. It's a bug class with a long history in Windows DNS — this isn't the first UAF Microsoft has patched in this component, and it won't be the last, because DNS message parsing is exactly the kind of complex, stateful, network-facing code where memory-safety bugs keep surfacing.

The attack surface is the DNS Server role itself, listening on port 53, parsing whatever query or update traffic gets sent to it. No authentication is required because DNS resolution, by design, has to work before authentication exists — that's the whole point of the protocol. There's no privilege check to add here without breaking DNS.

Why the affected component matters more than the CVSS score

A 9.8 unauthenticated RCE is bad wherever it lands. What makes this one worth a dedicated post is Microsoft's own longstanding guidance: install DNS Server on your domain controllers. It's the default recommendation in most AD deployment guides, it simplifies integrated DNS zones and secure dynamic updates, and as a result an enormous number of real-world Windows networks run DNS on the exact same box that holds the domain's authentication database, issues Kerberos tickets, and replicates AD data to every other DC in the forest.

So this isn't "a vulnerable service that happens to be on a server." For a large fraction of deployments, this is code execution on the domain controller. An attacker who lands here isn't pivoting toward the crown jewels — they're already standing on them.

Affected systems span Windows Server 2012 through Server 2025, including Server Core installations, plus Windows 10 1607 and 1809. Windows 11 isn't on the affected list, and neither are DNS clients — this is specifically the server role.

The part that should worry defenders more than attackers

As of this writing there's no confirmed in-the-wild exploitation. That's good news, but it's also the part of the story that tends to get forgotten fastest. Historically, unauthenticated RCEs in domain-facing Windows services (think PrintNightmare, the various Netlogon and DNS bugs before it) follow a predictable timeline: patch Tuesday, a few weeks of relative quiet, then a public proof-of-concept, then opportunistic scanning within days of that PoC landing. "No known exploitation yet" is a description of today, not a risk rating.

What this looks like from a training standpoint

This is a good teaching case for a few reasons that have nothing to do with the specific memory-corruption details (which, realistically, most defenders will never need to reproduce byte-for-byte):

Concept	Why CVE-2026-69730 illustrates it well
Blast radius vs. CVSS score	The number is the ceiling; the architecture around the vulnerable service decides whether you actually hit it
"Best practice" as attack surface	Microsoft's own recommended deployment pattern (DNS on the DC) is what makes this critical instead of merely bad
Patch prioritization under real constraints	Not every org can patch same-day; understanding why this one jumps the queue matters more than the CVE number
Defense in depth	Segmentation, monitoring, and patching aren't alternatives to each other — they're a stack, and this bug shows what happens when only one layer is in place

Teams that run domain-controller-adjacent labs — AD attack paths, lateral movement, privilege escalation content — should treat this as a prompt to revisit how their target environments model DNS placement. If your lab's domain controller also runs DNS (as most real ones do), it's worth walking students through why that configuration choice, made for entirely reasonable operational and manageability reasons, is also the thing that turns a service-level bug into a domain-level one.

The takeaway

CVE-2026-69730 isn't exotic. It's a memory-safety bug in a mature, well-understood service, discovered and patched through Microsoft's normal process. What makes it worth a Tuesday-morning read is the reminder that "critical" ratings are contextual — the same bug in an isolated, non-DC DNS resolver is a bad afternoon; on a domain controller with default deployment guidance behind it, it's a potential domain compromise from a single unauthenticated packet.

Patch it. If you can't patch it today, make sure whatever can reach port 53 on your domain controllers is a much shorter list than "the whole network," and treat that as a stopgap, not a plan.