CVE-2026-41089: Netlogon buffer overflow — one UDP packet takes down the entire domain

Sunday, 3 AM. LSASS crashes on the domain controller. Authentication, Kerberos, NTLM, group policies — all of it stops. Nobody can log into anything. The DC reboots on its own a minute later. While you’re still piecing together what happened, the second one goes down. Not a hardware failure. Not a misconfiguration. CVE-2026-41089.

It’s a stack-based buffer overflow in the Windows Netlogon service — CVSS 9.8, CWE-121. One unauthenticated UDP packet to port 389, and LSASS is gone. The whole domain is dead until the DC comes back up. Microsoft patched it on May 12, 2026 (KB5089549, May Patch Tuesday). Belgium’s Centre for Cybersecurity confirmed active exploitation in the wild on May 29.

Microsoft’s CVSS calls it RCE — C:H/I:H/A:H. Aretiq AI’s root cause analysis, published the day after the patch, tells a more nuanced story: the overflow mechanism makes arbitrary code execution unlikely in most configurations, because the bytes that spill past the buffer are the server’s own DNS data, not attacker-controlled content. But LSASS still crashes from a single packet. For a domain controller, that’s the same outcome. The DoS vs. RCE distinction stops mattering when one packet kills authentication across your entire organization.

WHAT NETLOGON IS

If a domain controller has ever gone down on your watch during business hours, you know exactly what follows. The helpdesk queue fills up in minutes. “Can’t log in.” “Nothing opens.” “Exchange is down.” Netlogon is why — it’s not some optional component you can disable and forget about. It’s what holds the whole domain together: the secure channel between machines and DCs, machine account password sync, inter-domain trust relationships. Pull it out and the domain doesn’t limp along — it stops.

The vulnerable piece is DC Locator. Before a client can log into the domain, it has to find a domain controller. It does that by sending a CLDAP request — Connectionless LDAP, UDP port 389 — with the domain name, a username, and a version flag (NtVer). The DC responds with its own details: server name, domain and forest names in DNS format, a GUID. None of this requires authentication, because the whole point is that the client doesn’t have credentials yet — it’s looking for somewhere to authenticate. That’s by design. And that’s what makes this attack surface so clean: the code has to accept requests from anyone.

HOW THE BUG WORKS

When a DC handles a CLDAP locator ping, BuildSamLogonResponse in netlogon.dll builds the response. It writes into a fixed 528-byte stack buffer: server name, the username from the request, domain name, two GUIDs, then the forest, domain, and host DNS names in compressed format.

The writing is done by NetpLogonPutUnicodeString. Three arguments: source pointer, max character count, cursor into the output buffer. No fourth argument. No buffer size. The function copies in a loop until it hits the character limit — and never checks whether it’s written past the end of the buffer. That’s the bug. Classic CWE-120.

BuildSamLogonResponse calls it three times with hardcoded limits: 36 chars for the server name, 130 for the username (straight from the attacker’s request), 32 for the domain name. Then come the GUIDs and the DNS names via NlpUtf8ToCutf8. Those DNS names vary in length depending on the server’s own configuration — and that’s the key.

The attacker controls the User field — up to 130 wide characters, 260 bytes. It’s the biggest single piece of the packet. It fills the middle of the buffer and shoves the server’s DNS names toward the end. The bytes that overflow past the 528-byte boundary are the DC’s own DNS data. The attacker decides how far everything gets pushed, but not what overwrites memory beyond the buffer. That’s why exploitation depends on DNS domain length: a short domain like example.com keeps the total under 528 bytes — no overflow. A long one like dept.division.engineering.enterprise.corporation.local with a 63-character hostname (the DNS label maximum) — the data doesn’t fit, and the DC crashes.

HOW IT IS EXPLOITED

Craft a CLDAP SearchRequest, send it to UDP 389 on the target DC. The filter needs DnsDomain set to the domain name, User with 130 characters of payload, and NtVer set to 0x00000002. That last value matters: bits 2–3 must be clear to route execution through BuildSamLogonResponse instead of BuildSamLogonResponseEx. Legitimate clients almost always send NtVer=6 — so NtVer=2 is a detection signal worth watching for.

The entire code path from CLDAP packet to vulnerable function runs before any credential check. DC Locator operates pre-authentication by design — there’s nothing to gate on.

When the overflow hits, it corrupts the GS stack cookie in BuildSamLogonResponse. Windows detects it, calls __fastfail(FAST_FAIL_STACK_COOKIE_CHECK_FAILURE), and LSASS terminates with 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN). No recovery — the system reboots.

WHAT HAPPENS NEXT — DEPENDS ON CONFIGURATION

The attacker sends the packet and gets a timeout. On the DC, LSASS is gone — Kerberos, NTLM, the Netlogon secure channel, group policy enforcement, all of it. No new logins. Active sessions drop. Anything relying on Kerberos tickets loses access.

Multiple DCs buy time — clients fail over. Until the attacker hits the next one. A single DC means a full outage until reboot. Multiple DCs mean a methodical takedown, one packet each, until nothing’s left standing. That’s a sustained, deliberate denial of service against your identity infrastructure.

Getting to arbitrary code execution is a different story. The overflowing bytes are the server’s compressed DNS names — not attacker data. The GS cookie breaks at just 2 bytes of overflow, but the return address for NlGetLocalPingResponse is 72 bytes past the buffer end. Maximum measured overflow with a 63-character DNS label is about 51 bytes. Even in the worst-case configuration, the attacker is 21 bytes short of the return address.

REAL-WORLD ATTACK CHAIN

The attacker needs a foothold somewhere that can reach UDP 389 on the DCs — a compromised workstation, a guest VLAN with weak segmentation, a VPN tunnel. From there, one packet.

The DC goes down within seconds. Monitoring flags an unexpected reboot — but by the time the on-call engineer has their laptop open, the attacker is already on the second DC. Then the third. In a flat network where UDP 389 is open everywhere, all the DCs can be sequentially knocked out in minutes. While they’re cycling through reboots, nobody authenticates: not users, not services, not scheduled tasks with Kerberos tickets. Ransomware operators love this window — deploy the encryptor while the admins are scrambling to figure out why nobody can log in and every remediation step requires explaining to three different people why their credentials aren’t working.

ZeroLogon (CVE-2020-1472) played out exactly the same way — Netlogon, pre-auth, DC takeover, weaponized within days. CCB clearly remembered that when they issued the emergency alert for CVE-2026-41089.

TIMELINE

May 12, 2026. Patch Tuesday. Microsoft ships KB5089549, marks CVE-2026-41089 as not exploited, not publicly disclosed, exploitation “less likely.” Same day, Aretiq AI drops a full root cause analysis: the vulnerable function, SHA256 hashes for both the broken and fixed binaries, and a PoC. The patch wasn’t through corporate WSUS rollouts yet.

Then 17 days of quiet. On May 29, CCB updates its advisory: actively exploited, patch immediately. June 1, a standalone emergency alert. Attribution: nothing public.

Seventeen days from patch to confirmed exploitation. That’s not unusual anymore — it’s the baseline. AI-assisted patch diffing can reconstruct the vulnerable code path in hours. Your change advisory board approval process for production DCs probably takes longer than that. This isn’t an argument for skipping testing. It’s an argument for having a tested, rehearsed DC patch procedure ready before the next Netlogon CVE lands.

WHY IT MATTERS

A domain controller isn’t just another server. It’s the identity plane for your entire organization. You don’t need RCE to cause damage — a reliable crash-on-demand is enough. Every minute a DC is down, authentication is broken for everyone in the domain. In a large environment, that’s measured in lost productivity across hundreds or thousands of people, plus whatever downstream services depend on AD.

Linux admins in mixed environments aren’t off the hook. If your Linux servers authenticate against the domain via SSSD or winbind, a dead DC takes them down too. Services that grab Kerberos tickets at startup fail. PAM-based logins stop working. The Windows problem becomes your Linux problem.

One thing worth checking before you panic: short domain names may not be vulnerable at all. If your DNS domain is something like corp.local, the total response data might never reach 528 bytes. The risk zone is deeper subdomain hierarchies — servers.eu.division.company.internal style. Check the character count on your DC’s DNS domain name. Over 50 characters with a long hostname, and this needs to be patched now, not next cycle.

UPDATE

The fix is KB5089549 — Windows Server 2025 build 26100.32860. All other supported Server versions got patches in the same May Patch Tuesday. For end-of-life systems (Server 2008 R2, 2012, 2012 R2), Acros Security has released micropatches via 0patch.

Check your netlogon.dll version on Server 2025:

Get-Item C:\Windows\System32\netlogon.dll | Select-Object -ExpandProperty VersionInfo | Select FileVersion, ProductVersion

Vulnerable: 10.0.26100.32684 (SHA256: C1F5FA84AE46E1A39592284EBB354BD055743D72AB417C1B90A7D99383289594). The patched build contains Feature_404993339 and replaces the unsafe copy loop with RtlStringCbCopyExW.

Verify the patch is installed:

Get-HotFix -Id KB5089549

Output means patched. No output means vulnerable.

Jason Kikta from Automox said it well: “half-patched forests are not a defensible state for a pre-auth DC bug.” Patch every DC in the same window. One unpatched controller is all the attacker needs.

If you can’t patch immediately, restrict CLDAP at the network layer. Block UDP 389 from external and untrusted segments at the perimeter. Inside the network, segment: workstations shouldn’t have direct UDP 389 access to DCs unless something specifically requires it. This doesn’t eliminate the vector — DC Locator needs CLDAP — but it shrinks the attack surface significantly.

Watch for: unexpected Netlogon service restarts, CLDAP traffic from unexpected sources, authentication failures spiking right after unusual DC-bound network activity.

CONCLUSIONS

The most dangerous vulnerabilities aren’t in obscure third-party libraries — they’re in the infrastructure every Windows shop has been running for decades and stopped thinking about. Netlogon is in every domain. UDP 389 is open on every DC. And this isn’t the first time Netlogon has been the way in.

If you run domain controllers: install KB5089549, check your DNS domain length, lock down UDP 389 where you can, and set up alerting for LSASS restarts. Exploitation is already happening. “We’ll patch it carefully” is fine — just make sure carefully also means fast.