If your organisation runs Windows Server and relies on Active Directory, there was a vulnerability disclosed in May 2026 that warrants immediate attention. It lives in Netlogon, the service that underpins authentication for every machine joined to your domain, and it requires nothing from an attacker except network access to a domain controller. No credentials. No prior foothold. One malformed UDP packet.
The vulnerability is CVE-2026-41089, a stack-based buffer overflow in the Windows Netlogon service with a CVSS v3.1 score of 9.8. It was patched by Microsoft on May 12, 2026, as part of Patch Tuesday. Active exploitation of unpatched domain controllers was confirmed by Belgium's national cybersecurity authority by June 1. There is no workaround or configuration mitigation: the only fix is the patch.
What is Netlogon and why does it matter?
Netlogon is a core Windows Server background service and remote procedure call (RPC) interface that handles authentication for domain-joined systems. When a user logs into a machine on your corporate network, when a workstation validates its domain membership, when a server authenticates a service account, Netlogon is involved in all of it. It is one of the most foundational services in a Windows Active Directory environment, and it runs on every domain controller in your fleet.
That centrality is exactly what makes CVE-2026-41089 so significant. Netlogon is not an optional component that some deployments disable, nor a peripheral feature with limited exposure. It is always running, always reachable on the network, and by design it must be able to receive connection requests from machines that have not yet proven their identity. The attack surface is every network path to a domain controller.
Netlogon has a documented history of serious vulnerabilities. The most notable precedent is Zerologon (CVE-2020-1472), a critical authentication bypass disclosed in 2020 that allowed any attacker on the local network to instantly compromise a domain controller. CVE-2026-41089 is a different bug in the same service, and the pattern should prompt the same urgency.
What is CVE-2026-41089?
The vulnerability was discovered internally by Microsoft's Windows Attack Research & Protection (WARP) team, an offensive cybersecurity and engineering research group inside Microsoft, and patched as part of the May 12 Patch Tuesday release alongside 136 other issues.
Microsoft's advisory describes the flaw as a stack-based buffer overflow (CWE-121) in the Netlogon service. The root cause is straightforward: a data serialization path in Netlogon accepts a network-supplied field from an incoming request and combines it with the server's own hostname to produce a derived value. There is no bounds checking on the attacker-supplied field. When the combined value exceeds the allocated stack buffer, the overflow occurs.
The crafted packet does not need to be particularly sophisticated. The attacker supplies an oversized value in one field, sends the packet over UDP, and Netlogon's processing logic does the rest. There is nothing exotic about the trigger: it is a classic stack buffer overflow, the kind of bug that has been considered well-understood and preventable for decades.
What an attacker can do
The immediate impact of successful exploitation is SYSTEM-level remote code execution on the target domain controller. The Netlogon service runs as SYSTEM, so any code execution that results from triggering the overflow runs with full operating system privileges. The attacker does not need to escalate after gaining a foothold: they arrive with the highest privilege level available.
From SYSTEM access on a domain controller, the options available to an attacker are effectively unlimited within the scope of the domain. They can create or modify accounts at any privilege level, including Domain Admin accounts. They can issue Kerberos Ticket-Granting Tickets, which provide authenticated access to most resources across the entire domain. They can disable security controls, deploy malware, exfiltrate Active Directory credential stores, or establish persistent access that survives reboots and incident response attempts.
The denial-of-service path is also available without full exploitation: it is trivial for an unauthenticated attacker on the network to trigger a crash of the LSASS process on a domain controller, forcing a reboot. This alone is sufficient to cause significant operational disruption in environments where domain controller availability is essential.
There is no authentication required. There is no user interaction required. There is no session, no prior access, and no social engineering step. Any attacker who can send a UDP packet to port 49152–65535 (or whichever ephemeral port the Netlogon RPC endpoint is bound to) on a domain controller can trigger this vulnerability.
Why a single vulnerable DC is enough
Medium and large enterprise environments typically run multiple domain controllers for redundancy and load distribution. This architecture, which is generally a strength, works against defenders in this scenario. If an attacker can reach any one domain controller, even one that is considered secondary or less exposed, and exploit it to obtain SYSTEM access, they can use that position to pivot to all other domain controllers in the domain. One unpatched machine in the fleet creates risk for the entire environment.
Security practitioners who have handled ransomware incidents will recognise this pattern. Domain controller compromise is typically the objective that enables mass deployment of ransomware or other destructive payloads across an enterprise. Netlogon is the entry point; the domain is the target.
Who is affected?
CVE-2026-41089 affects all supported Windows Server versions operating as domain controllers. The NVD configuration data confirms the vulnerable range spans Windows Server 2012, 2012 R2, 2016, 2019, 2022, 2022 23H2, and 2025. There is no supported version that is exempt; the vulnerability is present up to and including the most recent Windows Server release.
Windows client editions are not affected. The vulnerability is in the Netlogon service as exposed by servers configured as domain controllers, not in the broader Windows networking stack.
The absence of a minimum version floor is notable. Windows Server 2012 and 2012 R2 reached end of extended support in October 2023, but Microsoft has patched them here regardless - an indication of how seriously this vulnerability is being treated. Organisations still running those releases have the patch available to them, but should treat this event as a renewed prompt to plan migration to a supported version.
Disclosure and exploitation timeline
- May 12, 2026: Microsoft publishes the CVE and patches it as part of Patch Tuesday. The advisory describes the vulnerability as not publicly known and not exploited at the time of release. Microsoft's initial exploit likelihood assessment did not flag this as among the most likely issues to see imminent exploitation; an assessment that would prove incorrect within weeks.
- May 12, 2026 onwards: A GitHub repository containing proof-of-concept code that triggers a crash of the LSASS service on a target domain controller becomes circulated. This represents the DoS path rather than full RCE, but it confirms the vulnerability is exploitable with minimal effort.
- June 1, 2026: Belgium's Centre for Cybersecurity (CCB), the country's national cybersecurity authority, issues a warning that threat actors are now actively exploiting CVE-2026-41089 in the wild and urges administrators to apply patches immediately.
- June 1, 2026: Multiple security outlets including BleepingComputer and SecurityWeek report on the CCB warning. Microsoft, responding to media inquiries, states it has no evidence to support the exploitation claim but recommends customers install the available updates.
The gap between disclosure and confirmed exploitation here is approximately three weeks; longer than for some of the vulnerabilities covered in our recent Linux LPE series, but still well within the window that many organisations' patching cycles do not cover for server infrastructure. Domain controllers, in particular, often require careful change management before patching, which can extend that window significantly.
What should you do?
There is no configuration mitigation, no firewall rule that eliminates the risk without breaking Netlogon functionality, and no module to blocklist. The only remediation is the patch.
1. Identify all domain controllers in your environment
Before patching, establish a complete inventory of all Windows Server machines configured as domain controllers, including secondaries, read-only domain controllers (RODCs), and any DCs in branch offices or remote sites that may be managed less frequently. Use your SIEM, CMDB, or Active Directory Sites and Services to enumerate the full set.
# Enumerate all domain controllers in the current domain
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem, IPv4Address, Site
2. Apply the May 2026 Patch Tuesday updates immediately
Install the May 12, 2026 cumulative update for each affected server. This update addresses CVE-2026-41089 along with a significant number of other issues. Specific KB numbers by version:
| Windows Server Version | KB Article |
|---|---|
| Windows Server 2025 | KB5058392 |
| Windows Server 2022 23H2 | KB5058385 |
| Windows Server 2022 | KB5058385 |
| Windows Server 2019 | KB5058392 |
| Windows Server 2016 | KB5058392 |
| Windows Server 2012 R2 | KB5058392 |
| Windows Server 2012 | KB5058392 |
Check the Microsoft Security Update Guide for the definitive mapping of KB articles to product versions. After applying updates, verify the patch is in place:
# Check installed updates on a domain controller
Get-HotFix | Where-Object { $_.InstalledOn -gt (Get-Date "2026-05-01") } | Sort-Object InstalledOn -Descending
3. Prioritise domain controllers in your patching sequence
If you cannot patch all systems simultaneously, apply a risk-based sequence. Domain controllers that are directly reachable from less-trusted network segments - exposed to partner networks, accessible from workstation VLANs without intervening firewall inspection, or reachable from cloud environments - should be patched first. Internet-facing DCs, if any exist in your architecture, are the highest priority of all.
The adversary recommendation from the security community is to treat this as a worm-capable threat and patch all linked domain controllers as a coordinated batch rather than sequentially. A patched primary DC does not protect an unpatched secondary from direct exploitation if an attacker can route to it.
4. Verify the patch is actually installed and running
A patch that is installed but not applied, because a required reboot has not occurred, provides no protection. After deploying the update, verify that the restart has completed and that Windows reports the patched build number as running:
# Confirm current build on the domain controller
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").CurrentBuildNumber
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").UBR
5. Review network access to Netlogon endpoints
While not a substitute for patching, reviewing which systems and network segments have direct access to your domain controllers is sound hygiene regardless of this specific vulnerability. Netlogon operates over RPC using dynamic port assignment in the ephemeral range by default, though it can be configured to use a fixed port. If your domain controllers are reachable from network segments that have no legitimate need to authenticate to Active Directory, this is an opportunity to review those paths.
In particular, verify that domain controllers are not directly reachable from your DMZ, from third-party partner network connections, or from cloud workloads that have been given broad network access. The correct answer for most of these is to route authentication traffic through a more controlled path.
6. Monitor for signs of exploitation
Exploitation of CVE-2026-41089 may manifest in several ways in your logs. Watch for:
Unexpected LSASS crashes or domain controller reboots. The DoS path produces abrupt LSASS termination events. These will appear in the Windows Event Log as critical errors under the LSASS source and will produce event ID 1000 or similar application fault entries.
# Check for recent LSASS faults on a domain controller
Get-WinEvent -LogName Application | Where-Object { $_.ProviderName -eq "Application Error" -and $_.Message -like "*lsass*" } | Select-Object TimeCreated, Message -First 20
Anomalous account creation or privilege assignment. Successful exploitation leads to SYSTEM access, which an attacker will use to create persistence. New Domain Admin accounts, new privileged service accounts, or modifications to existing accounts in the days following exploitation disclosure are red flags. Alert on user account creation events (4720) and group membership changes (4728, 4732) for privileged groups.
Unusual Netlogon RPC traffic. If you have network flow data or packet capture capability on segments adjacent to your domain controllers, look for unexpected sources sending traffic to Netlogon endpoints. Legitimate Netlogon traffic comes from domain-joined machines; traffic from unexpected sources or external addresses is anomalous.
Kerberos ticket anomalies. If an attacker has used domain controller access to issue fraudulent Kerberos tickets, this may show up as authentications from unusual source IPs or for accounts that have no corresponding login session. Event ID 4769 (Kerberos service ticket request) with unusual service names or from unexpected clients is worth alerting on.
A note on Netlogon's history
This is not the first critical vulnerability in the Netlogon service, and it is unlikely to be the last. Zerologon in 2020 was a CVSS 10.0 vulnerability in the same service that allowed any network-adjacent attacker to immediately zero out the password of a domain controller's computer account and then use that to impersonate the DC. It was exploited by nation-state threat actors within weeks of disclosure.
The pattern that Zerologon established - a critical Netlogon vulnerability, rapid exploitation, domain-wide consequences - is repeating here. The Netlogon protocol is complex, handles trust relationships across the entire domain, and must accept input from machines that have not yet authenticated. It is, structurally, a difficult surface to harden, and it has the highest possible impact if compromised. Security teams should treat any Netlogon vulnerability with CVSS scores above 8.0 as requiring emergency patching procedures, not normal maintenance cycle treatment.
Summary
| CVE | CVE-2026-41089 |
| CVSS Score | 9.8 (Critical, v3.1) |
| Type | Stack-based Buffer Overflow (CWE-121) |
| Component | Windows Netlogon service |
| Discovered by | Microsoft WARP (Windows Attack Research & Protection) |
| Patched | May 12, 2026 (Patch Tuesday) |
| Affected | All supported Windows Server versions (2012 through 2025) configured as domain controllers |
| Attack vector | Network — unauthenticated, zero user interaction required |
| Immediate impact | SYSTEM-level RCE on domain controllers; trivial DoS path also available |
| Active exploitation? | Yes — confirmed by Belgium CCB, June 1, 2026 |
| Public PoC? | Yes — DoS path demonstrated; full RCE PoC circulating |
| Mitigation short of patching? | None — patching is the only fix |
| Full fix | May 2026 Patch Tuesday cumulative update for affected Windows Server versions |
With active exploitation confirmed and no configuration workaround available, the calculus here is simple: every unpatched domain controller in your environment is a potential entry point for complete domain compromise. If your Patch Tuesday cycle has not yet covered domain controllers, prioritise them now. If you need help auditing your DC inventory, validating patch deployment, or reviewing detection coverage for signs of prior exploitation, get in touch. Netlogon has a history of being in attackers' crosshairs, and CVE-2026-41089 is its most serious reappearance since Zerologon.