Microsoft’s May 2026 patch for CVE-2026-41089 fixed a byte/WCHAR mismatch in Netlogon’s CLDAP response serialization — a textbook buffer overflow on Domain Controllers, rated CVSS 9.8. Yeray at ADscan published an excellent patch-diff showing exactly what changed. We wanted to answer a different question: is this actually exploitable, and if so, how?

The Server-Side Reality

The public narrative — unauthenticated UDP packet crashes LSASS on any DC — doesn’t hold up in practice. Through lab reproduction and binary analysis, we confirmed two constraints that Microsoft’s “Exploitation Less Likely” rating hints at:

  1. NtVer routing: The vulnerable serialization path only fires when (NtVer & 0xc) == 0 and (NtVer & 0x2) != 0. Every public PoC we found sends NtVer values with bit 2 set (0x06, 0x16), which routes to the safe BuildSamLogonResponseEx path. The overflow requires NtVer=0x02.

  2. Buffer geometry: The response buffer is ~528 bytes on all modern builds. To escape it, the DC’s own DNS domain name must be at least 98 characters long. Default deployments (corp.local, ad.contoso.com) cannot crash — the attacker doesn’t control the field that causes the overflow to reach the buffer boundary.

So: real bug, but the server-side path is a DoS against DCs with unusually long domain names. Not nothing, but not the RCE the score implies.

A More Interesting Path

Patch-diffing revealed the same vulnerable function (NetpLogonPutUnicodeString) is called from NetpDcBuildPing — a client-side function invoked when workstations perform DC discovery. This is a heap buffer, not stack. No /GS cookie. No domain-length precondition. The overflow size is controlled by the AccountName parameter, which an attacker could influence through poisoned DC responses.

On paper, this is the better primitive: heap metadata corruption on a domain-joined workstation, triggerable from the network via spoofed CLDAP or Netlogon mailslot responses. We built tooling to trigger DsGetDcName calls with oversized parameters through several entry points — NLA, Kerberos SSP, foreign domain trust resolution.

Validation

We tested across Server 2003 SP2, Server 2012 R2, Server 2016, and Server 2022:

  • Foreign domain trust bypass: Crafted packets to force mailslot-based DC discovery. Pcap shows CLDAP (UDP/389) used exclusively — zero UDP/138 mailslot traffic on any platform.
  • Kerberos SSP in-process: Routed through the same modern CLDAP codepath. Page heap on lsass detected no corruption.
  • Direct RPC trigger: DsrGetDcNameEx2 with crafted AccountName. Same result — CLDAP path only.

The mailslot code path containing NetpDcBuildPing is vestigial. It exists in the binary but is never invoked on any Windows version from 2003 SP2 onward. The DC locator was rewritten to use CLDAP exclusively at some point before Server 2003 SP2 shipped — the vulnerable client-side path is dead code that probably only executes against NT4 Backup Domain Controllers.

What We Shipped Instead

Since exploitation didn’t pan out, we focused on detection. The existing public Suricata rule (anchored on BER-encoded lengths >256 bytes) has an evasion gap: the overflow triggers at 66+ character usernames, but the rule only fires at 256+. We wrote rules keyed on the NtVer anomaly (0x02 without typical companion flags) — this catches the attempt regardless of payload length or DC vulnerability.

Conclusion

CVE-2026-41089 is a real overflow with two distinct paths, and both are effectively dead for exploitation:

  • Server-side requires configuration nobody has
  • Client-side is unreachable code on everything newer than NT4

The CVSS 9.8 score reflects the theoretical primitive. The practical risk is a DoS against DCs with 98+ character DNS domains — a narrow enough condition that most environments can deprioritize this patch relative to the score. Detection rules still matter: an attacker sending NtVer=0x02 CLDAP queries is probing for this bug whether or not your DCs are vulnerable.