CVE-2026-69730: The Critical Windows DNS Vulnerability Every Admin Should Patch Now

DNS is one of those infrastructure components administrators expect to be boring.

It should answer questions such as:

Where is dc01.example.local?

Where is mail.example.com?

What IP belongs to application.example.local?

Unfortunately, when the DNS server itself contains a remotely exploitable memory-corruption vulnerability, boring infrastructure becomes a very attractive attack surface.

Microsoft's September 2026 security updates fix CVE-2026-69730, a critical remote code execution vulnerability in Windows DNS Server.

Its CVSS score is:

9.8 / 10

The important characteristics are even more interesting:

Attack Vector:       Network
Attack Complexity:   Low
Privileges Required: None
User Interaction:    None
Impact:              Remote Code Execution

Microsoft rates the vulnerability as Critical and assesses exploitation as:

Exploitation More Likely

For Windows administrators, that combination deserves immediate attention.

Especially because in a large number of Active Directory environments, the machine running DNS is not some disposable DNS appliance.

It is the Domain Controller.

The vulnerability in one sentence

An unauthenticated attacker capable of sending specially crafted network traffic to a vulnerable Windows DNS Server may be able to trigger a use-after-free memory corruption condition and execute arbitrary code on the server.

Translated into administrator language:

Attacker
    ↓
Malicious DNS traffic
    ↓
Windows DNS Server
    ↓
Memory corruption
    ↓
Remote Code Execution

No login page.

No malicious Word document.

No user clicking an attachment.

No valid Active Directory account.

No administrator credentials.

The vulnerable service only needs to be reachable.

CVE summary

The CVSS vector is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Which translates roughly to:

AV:N    Network reachable
AC:L    Low attack complexity
PR:N    No privileges required
UI:N    No user interaction
C:H     High confidentiality impact
I:H     High integrity impact
A:H     High availability impact

The vulnerability was disclosed as part of Microsoft's September 2026 security updates.

Why this vulnerability matters

CVSS scores alone do not tell the whole story.

A 9.8 vulnerability in an obscure optional application is one thing.

A 9.8 vulnerability in a service running on your Domain Controllers is something very different.

A typical Active Directory environment looks something like this:

                 ┌───────────────────┐
Clients ────────►│ Domain Controller │
                 │                   │
                 │ Active Directory  │
                 │ Kerberos          │
                 │ LDAP              │
                 │ DNS               │
                 └───────────────────┘

Windows DNS commonly runs directly on Domain Controllers.

That means successful remote code execution against the DNS service may potentially mean code execution on one of the most privileged systems in the entire organization.

The problem is no longer simply:

DNS server compromised

It may become:

Domain Controller compromised

And that potentially means:

Active Directory compromised

What does "use-after-free" mean?

Applications constantly allocate and release memory.

Simplified:

Application:
Give me some memory.

Operating system:
Here you go.

Application:
I'm finished with it.

Operating system:
Memory is now free.

A use-after-free vulnerability occurs when software later tries to use that memory again after it has already been released.

Conceptually:

Allocate object
      ↓
Use object
      ↓
Free object
      ↓
Object should no longer exist
      ↓
BUG
      ↓
Program accesses freed memory

Under the right circumstances, an attacker may be able to manipulate the memory that replaces the freed object.

The result can progress from:

application crash

to:

attacker-controlled memory state

and potentially:

arbitrary code execution

CVE-2026-69730 is classified as:

CWE-416 — Use After Free

Windows DNS Server is not the same as the Windows DNS client

Every Windows computer uses DNS.

That does not mean every Windows workstation exposes the same attack surface.

The important component here is the:

Windows DNS Server service

Think:

Windows workstation
        ↓
DNS client
        ↓
Not the main server-side attack scenario

versus:

Windows Server
        ↓
DNS Server role
        ↓
TCP/UDP 53
        ↓
Relevant attack surface

So the first administrator question should be:

Which of my Windows servers actually run the DNS Server role?

Which Windows Server versions are affected?

The vulnerability affects supported and extended-support Windows Server generations including:

Windows Server 2025
Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012

Affected product metadata also includes some corresponding Windows 10 servicing branches because components are shared between Windows client and server codebases.

The important practical point is:

If the server runs Windows DNS Server, check the September 2026 security update status.

First question: do I have Windows DNS servers?

Open PowerShell as Administrator:

Get-WindowsFeature DNS

A DNS server should show something similar to:

Display Name                       Name    Install State
------------                       ----    -------------
[X] DNS Server                     DNS     Installed

If you see:

[ ] DNS Server

the DNS Server role is not installed on that machine.

Check whether the DNS service is running

Run:

Get-Service DNS

Example:

Status   Name   DisplayName
------   ----   -----------
Running  DNS    DNS Server

If you have:

DNS Server

and:

Status: Running

that machine belongs in your CVE-2026-69730 remediation inventory.

Find your Domain Controllers

In Active Directory:

Get-ADDomainController -Filter * |
Select-Object HostName, IPv4Address, Site

Example:

HostName              IPv4Address    Site
--------              -----------    ----
DC01.example.local    10.1.10.10     HQ
DC02.example.local    10.1.10.11     HQ
DC03.example.local    10.2.10.10     Branch

Do not simply assume that every DC runs DNS.

Verify.

For example:

Invoke-Command -ComputerName DC01,DC02,DC03 {
    Get-Service DNS -ErrorAction SilentlyContinue
}

Check whether port 53 is listening

DNS normally uses:

UDP 53
TCP 53

Check UDP:

Get-NetUDPEndpoint -LocalPort 53 -ErrorAction SilentlyContinue

Check TCP:

Get-NetTCPConnection -LocalPort 53 -State Listen -ErrorAction SilentlyContinue

A working DNS server should normally have listeners on port:

53

Test DNS from another server

From another Windows machine:

Resolve-DnsName microsoft.com -Server 10.1.10.10

Or test your AD zone:

Resolve-DnsName example.local -Server 10.1.10.10

Example:

Name            Type TTL Section IPAddress
----            ---- --- ------- ---------
example.local   A    600 Answer  10.1.10.20

You can also test TCP connectivity:

Test-NetConnection 10.1.10.10 -Port 53

Example:

ComputerName     : 10.1.10.10
RemotePort       : 53
TcpTestSucceeded : True

Remember:

Test-NetConnection tests TCP.

Normal DNS frequently uses UDP.

Check your Windows build

Run:

Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, BuildNumber

Example:

Caption                          Version          BuildNumber
-------                          -------          -----------
Microsoft Windows Server 2022  10.0.20348       20348

You can also use:

winver

But checking only the base build number is not enough.

Windows cumulative updates increase the servicing revision as well.

Check installed Windows updates

Run:

Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object -First 15

This gives you an immediate view of recently installed Windows patches.

But remember:

Patch approved

is not the same as:

Patch installed

and:

Patch installed

is not necessarily the same as:

Patched version running after reboot

Always verify the running system after maintenance.

Important: the September update also broke RDS

There is one extremely important complication with the September 2026 Windows updates.

The original September 8, 2026 security updates introduced Remote Desktop Services problems on some Windows Server systems.

Administrators reported symptoms including:

RDP connection failures

Remote Desktop login problems

RDS instability

Servers hanging during Remote Desktop configuration

MMC becoming unresponsive

File Explorer becoming unresponsive

This creates an awkward situation.

You have a critical DNS vulnerability that you absolutely want to patch:

CVE-2026-69730
CVSS 9.8

but the original September security update itself could cause problems with Remote Desktop Services.

Microsoft therefore released out-of-band updates on September 14, 2026 to address the RDS regression.

The practical lesson: don't blindly install the first September KB

As of September 16, 2026, administrators should not think about this as:

Find the CVE-2026-69730 patch

Instead think:

Install the latest applicable cumulative update
for the Windows Server version.

Why?

Because the newer out-of-band cumulative updates include the earlier security fixes while also addressing the RDS regression where applicable.

Examples include:

Windows Server 2025
KB5129235
Build 26100.33451

Windows Server 2022
KB5129237
Build 20348.5631

Windows Server 2019
KB5129238
Build 17763.9247

Windows Server 2016
KB5129239
Build 14393.9514

Therefore:

OLD approach:

September 8 security update
        ↓
DNS vulnerability fixed
        ↓
Possible RDS problems

Preferred approach after the OOB release:

Latest September cumulative/OOB update
        ↓
DNS vulnerability fixed
        +
RDS regression corrected where applicable

That is an important distinction for production administrators.

If you already installed the September 8 update

Do not panic.

First check whether the server actually experiences RDS problems.

Then check whether a newer applicable Microsoft cumulative update is available.

On affected Windows Server platforms, install the newer out-of-band update rather than removing the security update and returning the machine to a vulnerable state.

The bad response would be:

RDP stopped working
        ↓
Uninstall September security update
        ↓
Forget about it

Now RDP may work again...

but the critical DNS vulnerability may be back.

A better response is:

RDP problem detected
        ↓
Check Microsoft release health
        ↓
Install latest OOB cumulative update
        ↓
Restart
        ↓
Validate RDP
        ↓
Validate DNS
        ↓
Validate AD

Test RDP after patching

If Remote Desktop is important in your environment, add it to the maintenance checklist.

From another system:

Test-NetConnection DC01 -Port 3389

Example:

ComputerName     : DC01
RemotePort       : 3389
TcpTestSucceeded : True

This only confirms the RDP port is reachable.

It does not guarantee that authentication and the RDS stack are functioning correctly.

You should also perform a real test login where appropriate.

Check Remote Desktop Services

On the server:

Get-Service TermService

Expected:

Status   Name         DisplayName
------   ----         -----------
Running  TermService  Remote Desktop Services

After applying the September/OOB updates, validate:

RDP connection
authentication
desktop session
MMC
Server Manager
File Explorer

especially if that server is used heavily for remote administration.

Do not forget the console

This incident is also a good reminder:

A server should not be manageable exclusively through RDP.

For critical infrastructure, you should ideally have another recovery path such as:

Hyper-V console
VMware console
iLO
iDRAC
IPMI
BMC
cloud console
physical console

Otherwise an RDS regression can turn a normal patch problem into:

How do I get back into the server?

How urgent is CVE-2026-69730?

Look at the attack prerequisites.

The attacker needs:

Network access to the vulnerable DNS service

They do not need:

Windows credentials
Domain credentials
Administrator credentials
A logged-in user
A malicious attachment
A browser exploit

The CVSS properties are:

AV:N
AC:L
PR:N
UI:N

This is exactly the type of vulnerability administrators should prioritize.

Is the vulnerability being actively exploited?

At disclosure, Microsoft reported:

Publicly disclosed: No
Known exploitation: No
Exploitation: More Likely

That distinction matters.

There was no confirmed widespread exploitation at disclosure.

But:

No known exploitation

does not mean:

Safe to patch in three months

Microsoft explicitly considers exploitation more likely.

That should be enough reason to prioritize remediation.

Is it wormable?

You may see vulnerabilities like this described online as:

wormable

because the properties are concerning:

Network reachable
+
No authentication
+
Low complexity
+
No user interaction
+
Remote code execution

Those are certainly characteristics that could support automated exploitation.

But they do not automatically prove that a reliable self-propagating worm exists.

The technically accurate statement is:

CVE-2026-69730 has characteristics suitable for automated network exploitation, but that alone does not prove a self-propagating worm exists.

There is no need to exaggerate a CVSS 9.8 unauthenticated DNS RCE.

It is already serious enough.

Why Domain Controllers should be patched first

Consider a typical AD server:

DC01
 ├── Active Directory Domain Services
 ├── DNS
 ├── Kerberos
 ├── LDAP
 └── Global Catalog

An administrator may think of DNS as merely:

a network service

But the actual security boundary is:

DNS service
     ↓
Domain Controller operating system

If attackers achieve arbitrary code execution on that machine, you potentially have an Active Directory incident.

That is why DNS-enabled Domain Controllers should be near the front of the patch queue.

Internet-facing Windows DNS is an even bigger concern

Ask yourself:

Does this Windows DNS server genuinely need to accept DNS traffic from the entire Internet?

There is a big difference between:

Internet
   X
Firewall
   X
Internal AD DNS

and:

Internet
   ↓
UDP/TCP 53
   ↓
Domain Controller

Your Active Directory DNS server should generally not also be your public authoritative Internet DNS server.

A cleaner architecture is:

Internet
   ↓
Public authoritative DNS

while:

Internal network
       ↓
Windows AD DNS
       ↓
Domain Controllers

The roles serve different security zones.

Check your firewall exposure

You can inspect Windows Firewall rules:

Get-NetFirewallRule |
Where-Object {
    $_.DisplayName -match "DNS"
} |
Select-Object DisplayName, Enabled, Direction, Action

You can inspect port filters:

Get-NetFirewallPortFilter |
Where-Object {
    $_.LocalPort -eq 53
}

Look for unnecessary exposure such as:

Source:
Any

Destination:
Domain Controller

Port:
53

Action:
Allow

If DNS should only serve internal networks, restrict access appropriately.

Firewall restrictions are not the fix

Segmentation reduces risk.

It does not remove vulnerable code.

Think:

Firewall
   ↓
Reduces who can reach the vulnerability

while:

Security update
   ↓
Removes the known vulnerability

Those are very different things.

The actual remediation remains:

PATCH THE SERVER

What if you cannot patch immediately?

Production reality exists.

Maybe the server cannot be restarted right now.

Temporary mitigation should focus on reducing network reachability:

Internet
      X
      │
Windows DNS

Restrict port 53 from:

Internet
guest networks
untrusted VLANs
unnecessary server segments
VPN pools that do not need DNS access

But remember:

Internal-only does not mean safe.

If an attacker compromises a workstation inside your network, internal DNS may become reachable.

Network segmentation buys time.

It does not fix CVE-2026-69730.

A practical patching checklist

First identify the DNS role:

Get-WindowsFeature DNS

Check the service:

Get-Service DNS

Check port 53:

Get-NetUDPEndpoint -LocalPort 53

Get-NetTCPConnection -LocalPort 53 -State Listen

Check the OS:

Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, BuildNumber

Check installed updates:

Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object -First 15

Install the latest applicable cumulative Microsoft update, not necessarily the first September 8 package.

Restart where required.

Then validate DNS:

Resolve-DnsName microsoft.com -Server localhost

If the server is a Domain Controller:

dcdiag /test:dns

Check replication:

repadmin /replsummary

And because of the September RDS regression, also test:

Test-NetConnection localhost -Port 3389

plus a real Remote Desktop session if RDP is used.

Use DCDIAG after patching Domain Controllers

Run:

dcdiag /test:dns

For detailed output:

dcdiag /test:dns /v

Across the environment:

dcdiag /e /test:dns

After patching DNS-enabled Domain Controllers, verify:

DNS service running
AD zones loaded
DNS registrations healthy
forwarders working
AD-integrated zones available
clients resolving names

Do not consider patching complete simply because:

Windows Update: Successfully Installed

Infrastructure needs functional validation.

Check AD replication too

Run:

repadmin /replsummary

Then:

repadmin /showrepl

You do not want this:

DC01 patched successfully

followed several hours later by:

DC01 has not replicated since reboot.

Patch validation is part of patching.

Suggested patch order

If you have multiple DNS-enabled Domain Controllers:

DC01
DC02

do not patch and reboot both simultaneously.

Instead:

Verify DC02
     ↓
Patch DC01
     ↓
Restart DC01
     ↓
Test DNS
     ↓
Test AD
     ↓
Test replication
     ↓
Test RDP/RDS
     ↓
Continue with DC02

This maintains DNS and authentication availability during maintenance.

Example maintenance sequence

Suppose:

DC01 — 10.1.10.10
DC02 — 10.1.10.11

Both provide Active Directory DNS.

1. Verify DC02

Resolve-DnsName microsoft.com -Server 10.1.10.11

dcdiag /s:DC02 /test:dns

2. Patch DC01

Install the latest applicable cumulative update.

Restart.

3. Validate DC01

DNS:

Get-Service DNS

Resolve-DnsName microsoft.com -Server 10.1.10.10

AD DNS:

dcdiag /s:DC01 /test:dns

Replication:

repadmin /replsummary

RDS:

Get-Service TermService

Test-NetConnection DC01 -Port 3389

If RDP is used administratively, perform a real connection test as well.

4. Patch DC02

Only after DC01 has been confirmed healthy.

How to verify the vulnerability is actually closed

Do not stop at:

We deployed the update.

There are multiple stages:

Patch approved

is not:

Patch downloaded

which is not:

Patch installed

which is not:

Patched OS running after reboot

Your final evidence should include:

Server hostname
OS version
OS build
Installed KB
DNS role status
DNS service status
Restart completed
DNS functional test
AD health test
Replication test
RDS/RDP test

Example:

HOST: DC01

OS:
Windows Server 2022

BUILD:
20348.5631

DNS:
Running

DNS query:
PASS

DCDIAG DNS:
PASS

Replication:
PASS

RDP:
PASS

Now you have actual remediation evidence.

Don't forget forgotten DNS servers

The obvious machines are:

DC01
DC02

The dangerous machines are often:

OLD-DC
DR-DC
BRANCH-DC
TEST-DC
LEGACY-DNS

Inventory:

branch offices
disaster recovery sites
lab domains
child domains
old Domain Controllers
isolated networks
legacy Windows Servers

The most vulnerable Windows DNS server in your organization may not be the primary DC.

It may be the forgotten Server 2016 VM nobody has touched in years.

September contains multiple Windows DNS vulnerabilities

CVE-2026-69730 is not the only Windows DNS issue fixed in Microsoft's September 2026 security release.

Microsoft patched multiple DNS-related remote code execution vulnerabilities during the same release.

That is another reason not to think in terms of:

Install the CVE-2026-69730 patch

Windows Server security updates are cumulative.

The correct approach is:

Install the latest applicable cumulative update

so that the entire set of relevant DNS fixes is applied.

Monitoring after patching

After remediation, monitor for:

DNS service crashes

unexpected DNS.exe restarts

DNS query failures

unexpected DNS traffic spikes

unusual external sources contacting DNS

Windows Error Reporting events involving DNS

RDP/RDS failures

TermService problems

If you use:

Wazuh
Microsoft Sentinel
Defender
Splunk
Elastic
SIEM

consider monitoring both:

DNS service health

and:

Remote Desktop Services health

after the September updates.

What administrators should do today

If you run Windows DNS Server:

1. Inventory every Windows DNS server.

2. Identify which DNS servers are Domain Controllers.

3. Identify whether DNS is exposed to untrusted networks.

4. Check the current Windows build and installed KBs.

5. Check whether the server received the original September 8 update.

6. Check whether a newer September out-of-band cumulative update applies.

7. Install the latest applicable Microsoft cumulative update.

8. Restart if required.

9. Test DNS resolution.

10. Run DCDIAG on Domain Controllers.

11. Check AD replication.

12. Test RDP and Remote Desktop Services.

13. Record evidence that the server is healthy and patched.

Quick PowerShell checklist

Is DNS Server installed?

Get-WindowsFeature DNS

Is DNS running?

Get-Service DNS

Is UDP 53 listening?

Get-NetUDPEndpoint -LocalPort 53

Is TCP 53 listening?

Get-NetTCPConnection -LocalPort 53 -State Listen

Which Windows version is installed?

Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, BuildNumber

Which updates were recently installed?

Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object -First 15

Does DNS work?

Resolve-DnsName microsoft.com -Server localhost

Is Active Directory DNS healthy?

dcdiag /test:dns

Is replication healthy?

repadmin /replsummary

Is Remote Desktop Services running?

Get-Service TermService

Is RDP reachable?

Test-NetConnection localhost -Port 3389

The important lesson

The scary part of CVE-2026-69730 is not simply:

CVSS 9.8

It is where the vulnerable component often lives.

In an Active Directory environment:

DNS

is frequently running on:

the Domain Controller

And the Domain Controller is responsible for:

authentication
Kerberos
LDAP
computer trust
user accounts
group policies
directory data

That makes a Windows DNS remote code execution vulnerability fundamentally different from a vulnerability in some random utility installed on a workstation.

The vulnerable service can sit directly on one of the most privileged systems in the organization.

Final recommendation

If you operate Windows DNS Server, treat CVE-2026-69730 as a high-priority patching task.

The technical properties are bad enough:

Remote
+
Unauthenticated
+
Low complexity
+
No user interaction
+
Remote Code Execution
+
Frequently running on Domain Controllers

But September 2026 also gives administrators an additional complication:

Critical DNS vulnerability
        +
Original September update
        +
RDS regression

Do not solve the RDS problem by simply removing security updates and leaving the DNS vulnerability exposed.

Instead:

Find your DNS servers
        ↓
Check current KB/build
        ↓
Install latest applicable cumulative/OOB update
        ↓
Restart safely
        ↓
Test DNS
        ↓
Test Active Directory
        ↓
Test replication
        ↓
Test RDS/RDP

Then document the result.

Because:

"We installed Windows Updates."

is not evidence.

This is:

DNS: PASS
AD: PASS
Replication: PASS
RDP: PASS
Patched build: confirmed