Netlogon CVE-2026-41089: A Pre-Auth Domain Controller RCE and the Small-Business Patch-Now Playbook

On May 12, 2026, Microsoft patched CVE-2026-41089, a stack-based buffer overflow in the Windows Netlogon service that lets an unauthenticated attacker run code on a domain controller over the network. The flaw carries a CVSS 3.1 base score of 9.8. There is no password, no phishing click, and no foothold required - just a crafted Netlogon request to a server that answers as a domain controller. Success means SYSTEM-level code execution on the one box that defines identity for every other machine you own.

Microsoft's own offensive team, Windows Attack Research and Protection (WARP), found and reported the bug, and at release Microsoft rated it "Exploitation Less Likely." Three weeks later that label looks optimistic. On Friday, June 1, the Centre for Cybersecurity Belgium (CCB) warned that CVE-2026-41089 is "now actively exploited in the wild," citing intelligence from trusted partners. Microsoft has publicly responded that it found no evidence to support that claim while still telling customers to install the update. You do not get to wait for that disagreement to resolve. The patch shipped three weeks ago, the bug is pre-authentication, and the target is your domain controller.

For a small business this is not somebody else's enterprise problem. If you run Active Directory - and nearly every company with more than a handful of Windows machines does - you have at least one domain controller, and it is almost certainly reachable from every workstation, server, and VPN client on your network. That reachability is the entire point of a domain controller. It is also exactly what turns one unpatched DC into a full-domain compromise.

What CVE-2026-41089 actually is

Netlogon is the Windows service that brokers authentication between member machines and domain controllers. It runs over MS-NRPC, the Netlogon Remote Protocol, an RPC interface that every domain controller exposes by default. CVE-2026-41089 is a memory-safety bug in how that interface parses an incoming request: a malformed field overflows a stack buffer, and a careful attacker turns that overflow into code execution inside the Netlogon service, which runs as SYSTEM. Per the Microsoft Security Response Center advisory and the NVD entry, the attack vector is network, the attack complexity is low, and no privileges or user interaction are required.

If "Netlogon" plus "domain controller" plus "remote code execution" sounds familiar, it should. This is the same protocol surface that produced Zerologon (CVE-2020-1472) in 2020, the cryptographic flaw that let attackers reset a domain controller's machine password in seconds. CVE-2026-41089 is a different class of bug - a buffer overflow, not a crypto weakness - but the lesson is identical: the Netlogon RPC endpoint is one of the most valuable pieces of attack surface in any Windows environment, and it is listening on every DC the moment you promote it.

The vulnerability affects every currently supported Windows Server release, including Windows Server 2025. End-of-life builds - Server 2008 R2, 2012, and 2012 R2 - are affected too, and those have only third-party micropatches available. An out-of-support domain controller is now a liability you cannot patch through normal channels, which is reason enough to retire it.

Why one domain controller bug is a whole-network bug

Small teams sometimes treat a single server as a single risk. A domain controller breaks that intuition. SYSTEM on a DC is not "one compromised server" - it is the keys to the entire identity kingdom, and there is no clean way to walk it back after the fact.

What an attacker gets from SYSTEM on a domain controller

• The Active Directory database (ntds.dit), which holds the password hashes for every account in the domain, including every Domain Admin and the krbtgt account.
• The krbtgt hash, which is the master key for forging Golden Tickets - Kerberos tickets that authenticate as any user to any service, and that stay valid until you rotate krbtgt twice.
• Group Policy, which pushes configuration and arbitrary scripts to every domain-joined machine. One malicious GPO is a domain-wide deployment channel for ransomware.
• DNS, certificate enrollment through AD CS, and the trust relationships to any other domain or forest you federate with.

There is no segmentation story that contains this after the fact. Once a domain controller is SYSTEM-compromised, the credible incident response is not "reimage the box," it is "rebuild the forest and rotate every secret in it." For an organization with one or two IT people and a weekend maintenance window, that is days of downtime and a long tail of broken integrations. Patching three weeks ago was the cheap option. Patching today is still cheaper than the alternative.

The exploitation argument you should not get stuck in

The temptation right now is to wait out the disagreement between Microsoft and the CCB. Resist it. When a national CERT publishes an active-exploitation warning for a pre-authentication domain controller bug, the prudent default is to treat the bug as exploited, regardless of whether the vendor has independently confirmed the same telemetry. The downside of patching a DC that was never going to be attacked is a maintenance window. The downside of not patching a DC that was is forest reconstruction.

The exposure window is also closing on its own. Within days of any Patch Tuesday, researchers begin diffing the binaries Microsoft shipped to reverse-engineer the fix, and public root-cause analyses for CVE-2026-41089 are already circulating. A buffer overflow with a known patch is a finite reverse-engineering problem, and the gap between "patch released" and "reliable exploit in commodity toolkits" is measured in weeks, not quarters. As Jason Kikta, CTO at Automox, put it: "Half-patched forests are not a defensible state for a pre-auth DC bug." If you patch one domain controller and leave its replication partner for next month, you have not reduced your risk - you have only changed which IP the attacker targets.

Find every domain controller and confirm the patch

You cannot patch what you have not inventoried, and small environments routinely have a forgotten DC - a read-only domain controller at a branch office, a virtual machine spun up for a migration that never got decommissioned, a second DC someone stood up "for redundancy" and then stopped touching. Enumerate them all from the forest, then check each one's build number against the fixed revision for its OS version.

# Run from a domain-joined admin workstation with RSAT installed.
Import-Module ActiveDirectory

# Minimum patched revision (UBR) per Server build, from the May 2026 update.
$minUbr = @{
    14393 = 9140    # Windows Server 2016
    17763 = 8755    # Windows Server 2019
    20348 = 5074    # Windows Server 2022
    25398 = 2330    # Windows Server 2022 23H2
    26100 = 32772   # Windows Server 2025
}

Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    $cv = Invoke-Command -ComputerName $dc -ScriptBlock {
        $k = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
        [pscustomobject]@{
            Build = [int](Get-ItemProperty $k).CurrentBuildNumber
            Ubr   = [int](Get-ItemProperty $k).UBR
        }
    }
    $need  = $minUbr[$cv.Build]
    $state = if ($need -and $cv.Ubr -ge $need) { 'PATCHED' }
             elseif ($need) { 'VULNERABLE' } else { 'UNSUPPORTED-OS' }
    '{0,-22} build {1}.{2}  =>  {3}' -f $dc, $cv.Build, $cv.Ubr, $state
}

Anything that prints VULNERABLE is a same-day job. Anything that prints UNSUPPORTED-OS is a domain controller running an operating system Microsoft no longer patches, which is a larger problem than this one CVE. Apply the May 2026 cumulative update to every DC in the same change window, then reboot and re-run the check to confirm the revision actually advanced - a pending-reboot DC reports the old build and is still exploitable.

Detect probing and contain Netlogon while you finish

Exploiting a memory-corruption bug reliably is hard, and unreliable attempts crash the service before they land. That makes the Netlogon service itself a useful tripwire. Unexpected Netlogon stops and restarts on a domain controller, especially in clusters, are worth treating as a possible exploitation attempt until proven otherwise.

# On each DC: look for unexpected Netlogon service stops/restarts.
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 7031, 7034 } -MaxEvents 200 |
    Where-Object { $_.Message -match 'Netlogon' } |
    Select-Object TimeCreated, Id, @{ n = 'Event'; e = { $_.Message.Split([Environment]::NewLine)[0] } }

# Surface which non-DC hosts are talking to the DC's RPC endpoint mapper (TCP 135),
# the first hop for reaching the Netlogon interface.
Get-NetTCPConnection -LocalPort 135 -State Established |
    Select-Object -ExpandProperty RemoteAddress -Unique

You cannot firewall Netlogon off between domain controllers and legitimate clients - that is the authentication path for the whole domain. What you can do is make sure nothing that has no business authenticating to a DC can reach it. Guest Wi-Fi, IoT and camera VLANs, lab segments, and third-party VPN pools should not have a network path to domain controller RPC ports. Watch for the indicators the CCB and responders have flagged: Netlogon service crashes, anomalous Netlogon or RPC traffic sourced from non-domain-controller hosts, and authentication failures that cluster around that traffic. If you see exploitation signs on a DC you have not yet patched, treat it as a potential compromise and pull the AD response plan, not just the patch plan.

The move this week

Inventory every domain controller, confirm each one is on the May 2026 revision, and close the change window with zero DCs left behind. Make sure no untrusted network segment can reach a domain controller's RPC ports, and turn Netlogon service restarts into an alert your team actually sees. If any of your domain controllers are still on an out-of-support Windows Server build, this CVE is the forcing function to finally migrate them - because the next pre-auth Netlogon bug is coming, and there will be no patch for those boxes when it does.