CriticalVulnerabilityPatch available

Windows Netlogon CVE-2026-41089: pre-auth stack overflow on domain controllers, reported exploited

A CVSS 9.8 Netlogon overflow lets an unauthenticated attacker crash or take over Windows domain controllers. Install the May 2026 update on every DC.

Published
Updated
Fixed in
May 2026 security updates; Windows Server 2025 build 26100.32860, 2022 build 20348.5139, 2019 build 17763.8755, 2016 build 14393.9140
Exploitation
Disputed. Belgium’s CCB said exploited in late May 2026, citing trusted partners; Microsoft said it had no evidence; not in CISA KEV as of 30 October 2026

Live scores

CVE-2026-41089
EPSS
0.796
very likely to be attacked soon
VEDAS
0.977
strong exploit evidence
On CISA KEV
Not listed
Detection rule
None yet

What happened

Microsoft fixed CVE-2026-41089 on 12 May 2026. It is a stack-based buffer overflow in Windows Netlogon that “allows an unauthorized attacker to execute code over a network,” rated CVSS 9.8 (CVE record). Microsoft’s own Windows Attack Research & Protection (WARP) team found it, and Microsoft rated exploitation “less likely” at release (Help Net Security). All supported Windows Server versions are affected, from Server 2012 to Server 2025 (CVE record; BleepingComputer).

According to a Securonix analysis, the bug sits in netlogon.dll. When a domain controller answers a CLDAP “DC locator” ping on UDP port 389, it builds the reply in BuildSamLogonResponse. A helper treats a length in bytes as a count of wide characters, so a long User value in the request overruns a 528-byte stack buffer. Whether the public proof-of-concept path works depends on the length of the DC’s DNS domain and host name. Stack cookies limit reliable code execution, and Securonix says the activity seen so far has mostly been denial of service (Securonix).

Exploitation is reported but disputed. In late May, Belgium’s Centre for Cybersecurity (CCB) said the flaw “is now actively exploited in the wild.” A CCB spokesperson said the information came from “trusted partners” and gave no details. Microsoft told BleepingComputer it had no evidence supporting the claim (BleepingComputer). The CVE was not in CISA’s KEV catalog as of 30 October 2026 (CISA KEV).

Am I affected?

Every domain controller without the May 2026 update is affected. The fixed builds, from the CVE record (CVE record):

Windows ServerFixed at build
202510.0.26100.32860
2022, 23H2 (Server Core)10.0.25398.2330
202210.0.20348.5139
201910.0.17763.8755
201610.0.14393.9140
2012 R26.3.9600.23181
20126.2.9200.26079

List your DCs and read each one’s build and update revision:

powershell
# All domain controllers in the domain
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem

# On each DC: build and update revision (compare to the table)
$v = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"$($v.CurrentBuild).$($v.UBR)"

Server 2008 R2 and older are past support and get no Microsoft fix. Acros Security published 0patch micropatches for 2008 R2, 2012 and 2012 R2 (Help Net Security).

Signs of attempts, from Securonix (Securonix):

  • Application log Event ID 1000 with faulting application lsass.exe, faulting module netlogon.dll and exception code 0xC0000409, often followed by Event ID 6008 (unexpected shutdown) at the next boot.
  • System log Event IDs 7031 and 7034 for unexpected Netlogon termination.
  • UDP 389 traffic to DCs from hosts that are not DCs or normal clients, or CLDAP requests with unusually long User values.
powershell
Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000} |
  Where-Object { $_.Message -match 'netlogon\.dll' } |
  Select-Object TimeCreated, Message

What to do now

  1. Patch every domain controller in one window. Install the May 2026 cumulative update or later. Automox’s Jason Kikta: “half-patched forests are not a defensible state for a pre-auth [Domain Controller] bug” (Help Net Security).
  2. Restrict CLDAP to DCs. Allow UDP 389 to domain controllers only from known internal subnets, and block it at the perimeter (Securonix). Check for DCs reachable from the internet or from guest and partner networks.
  3. Hunt for crashes since 12 May. Search the Event IDs above on every DC. An lsass crash on a DC also forces a reboot, so unexplained DC restarts deserve a look.
  4. If a DC crashed with netlogon.dll as the faulting module, check for signs of follow-on activity: unexpected child processes of lsass.exe, bursts of Kerberos ticket requests and trust errors after the reboot (Securonix).
  5. Legacy DCs: retire them, or apply the 0patch micropatch as a stopgap and isolate them.

Sources