SecPod
← Back to Blog

CVE-2026-41089 Windows Netlogon CLDAP Stack-Based Buffer Overflow RCE

Jun 4, 2026

1 OVERVIEW

Vulnerability Name: Windows Netlogon CLDAP Stack-Based Buffer Overflow RCE

CVE ID: CVE-2026-41089

CVSS 3.1 Score: 9.8 CRITICAL CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVSS 4.0 Assessment (Aretiq AI): 8.8 HIGH - AT:P due to DNS naming prerequisites

Discovered By: Microsoft's Windows Attack Research & Protection (WARP) team (internal discovery, credited in the vendor advisory)

Published Date: May 12, 2026 (Microsoft May 2026 Patch Tuesday)

Affected Products / Versions


Note: While netlogon.dll is present on all Windows editions including client versions (Windows 10/11 various builds), the vulnerability is only exploitable on systems actively configured as Active Directory Domain Controllers, as the vulnerable CLDAP DC locator response handler is only active in that role.

Short Description

A stack-based buffer overflow in the Windows Netlogon service's DC locator ping response handler (netlogon.dll) allows an unauthenticated remote attacker to send a single crafted UDP packet to port 389 (CLDAP) and overflow a 528-byte stack buffer inside LSASS on a domain controller. The result is an LSASS crash (STATUS_STACK_BUFFER_OVERRUN, 0xc0000409), forcing a DC reboot and causing domain-wide authentication outage for ~60 seconds.

Full remote code execution at SYSTEM level is theoretically possible given the attack vector and Microsoft's own CVSS scoring, though in practice the GS stack cookie and the nature of the overflow content (server-controlled DNS data rather than attacker-controlled bytes) make reliable RCE extremely difficult. The flaw requires no authentication, no credentials, no user interaction, and no prior foothold - one packet is sufficient. Microsoft issued patches on the same day as disclosure. Active exploitation in the wild was confirmed by the Centre for Cybersecurity Belgium (CCB) on June 1, 2026.

2 EXPLOIT MATURITY ASSESSMENT

3 PROOF OF CONCEPT (PoC)

Publicly Available: Yes

PoC Links
  • https://github.com/0xABCD01/CVE-2026-41089 (public GitHub, Python 3.8+, no third-party dependencies, MIT license - 17 stars, 8 forks as of research date)
  • https://aretiq.ai/research/vul260513-cve-2026-41089-microsoft-windows-netlogon-buildsamlogonresponse-stack-based-buffer-overflow-rce (enterprise-verified download, detailed Python PoC with pyasn1)
  • https://blog.0patch.com/2026/05/micropatches-released-for-windows_0304568783.html (0patch micropatch analysis with root cause commentary)
Description of PoC (GitHub: 0xABCD01/CVE-2026-41089, poc.py)

Purpose: Demonstrate and test the CLDAP stack buffer overflow against an unpatched Windows Server Domain Controller to confirm reachability and trigger the LSASS crash condition.

Prerequisites

  • Target must be a Windows Server DC (any version 2012–2025) without the May 2026 patch applied
  • Target must have UDP port 389 accessible from the attacker (or at minimum not blocked at perimeter)
  • For guaranteed crash: the target DC's DNS domain name must be approximately 50+ characters in total length (e.g., dept.division.engineering.enterprise.corporation.local); DCs with short domain names (e.g., "example.com") are not vulnerable due to the combined response data not reaching 528 bytes
  • Attacker machine: Python 3.8+ with no third-party packages (GitHub PoC) or pyasn1 (Aretiq PoC)

Expected Outcome: The PoC sends a normal CLDAP ping first to confirm DC liveness, then sends an overflow ping containing a 130-character username ("A"×130). If LSASS crashes, the subsequent liveness check times out. Within ~60 seconds, the DC reboots. LSASS crash is logged as Event ID 1000 with faulting module netlogon.DLL and exception code 0xc0000409.

4 PoC REPRODUCIBILITY

Can PoC be built from available information?: Yes

Required Tools / Dependencies

  • Python 3.8+ (standard library only for GitHub poc.py; pyasn1 needed for Aretiq version)
  • CLDAP is UDP, so no TCP handshake required - any network path to UDP 389 on the DC works

Usage:

python3 poc.py <target_ip> <domain_name> [-l 130] [-t 5] [-d 3]

High-Level Execution Steps

1. Connectivity test - send CLDAP ping with a short username (e.g., "testuser") to confirm the DC responds on UDP 389 and to establish a baseline.

2. Send overflow ping with a 130+ character username of repeated "A" characters. The long username is placed in the "User" filter attribute of a CLDAP SearchRequest targeting the rootDSE with NtVer=0x02000000. The crafted packet forces the non-EX response path through BuildSamLogonResponse rather than BuildSamLogonResponseEx.

3. Wait the configured delay (default 3 seconds). Send a normal ping. If no response is received (recv timeout), LSASS has gone down. DC will reboot within ~60 seconds and authentication will resume after reboot.

4. Confirm by checking Event Viewer on the target: Application log, Event ID 1000, faulting application lsass.exe, faulting module netlogon.DLL, exception code 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN).

Key Flags

5 TIME-TO-EXPLOIT ANALYSIS

6 ACTIVE EXPLOITATION & THREAT ACTORS

Exploitation Observed in the Wild: Yes

Confirmed by the Centre for Cybersecurity Belgium (CCB) on June 1, 2026, via their public alert on the May 2026 Patch Tuesday advisory tracking 118 vulnerabilities, 16 critical, with CVE-2026-41089 singled out for active exploitation. CCB has not yet publicly disclosed specific attack details, campaign names, or IOCs from the in-progress exploitation at the time of this writing.

Associated Threat Actors

No specific APT groups, ransomware gangs, or Initial Access Brokers have been publicly attributed to the observed in-wild campaigns as of June 2, 2026. The CCB warning was issued without associated threat actor attribution. Given the nature of the vulnerability (unauthenticated pre-auth DC kill) and the rapid PoC availability, the attack surface is consistent with:

  • Initial Access Brokers targeting Active Directory environments for resale
  • Ransomware operators seeking fast domain takeover paths (consistent with the "inside-the-perimeter fast path to forest-wide takeover" framing from Automox CTO Jason Kikta)
  • Nation-state or espionage actors targeting government and critical infrastructure domain controllers
Campaign Details

7 VULNERABILITY TIMELINE

8 PATCH / MITIGATION

Patch Available: Yes

Patch Version and Details

The May 2026 Patch Tuesday update (released May 12, 2026) addresses CVE-2026-41089 across all supported Windows Server versions:

Download Link: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-41089


Updates are distributed via Windows Update, WSUS, and the Microsoft Update Catalog.



Technical Nature of the Fix


The patch introduces feature flag Feature_404993339 in netlogon.dll. When enabled, the unsafe NetpLogonPutUnicodeString function (which had no output buffer size parameter and performed unbounded character-by-character writes) is replaced with a new bounded version using RtlStringCbCopyExW with a byte-count budget rather than a character count. The patched version returns a DWORD error code (0 = success, 87 = ERROR_INVALID_PARAMETER) and the caller aborts on any error. The old function is preserved as NetpLogonPutUnicodeStringOld behind the feature flag for comparison. Additionally, NlGetLocalPingResponse now zero-initializes the 528-byte stack buffer when the flag is active.



Patched netlogon.dll SHA256: A59733767285859FC3F982C46EA9C1173F4BF025D1569C03B4D137B55132B2DB

Important Operational Note : Admins should patch all domain controllers within the same maintenance window. "Half-patched forests are not a defensible state for a pre-auth Domain Controller bug." This means patching some DCs but not others leaves the environment at full risk from any single unpatched DC.

Workarounds and Mitigations (for systems that cannot immediately patch)

5. Restrict inbound UDP 389 (CLDAP) and TCP 445 / Netlogon RPC to known, trusted management subnets using host firewalls (Windows Firewall / Advanced Security rules) and network perimeter/internal firewalls. Do not expose domain controllers' Netlogon RPC endpoints to untrusted or Internet-facing networks.

6. Apply IPsec policies or RPC filters to limit Netlogon endpoint access to authenticated domain members only.

7. Enforce network segmentation - any flat internal network where any host can reach a DC on UDP 389 is at heightened risk.

8. For legacy EoL versions (Server 2008 R2): Apply patch micro patches from Across Security as a temporary measure.

9. Increase monitoring on all domain controllers (see Detection section).

Detection Tips
  • Log Pattern 1: CLDAP SearchRequests containing a "User" filter attribute with more than 20–30 characters. Normal DC locator pings use short service account names or omit the User attribute entirely.
  • Log Pattern 2: Windows Application Event Log, Event ID 1000, faulting application lsass.exe, faulting module netlogon.DLL, exception code 0xc0000409.
  • Log Pattern 3: NtVer attribute value of 0x02000000 (little-endian) in CLDAP pings - legitimate clients nearly always set NtVer=6 which takes a different (non-vulnerable) code path through BuildSamLogonResponseEx.
  • Behavioral Indicator: The Netlogon service unexpectedly crashing or restarting; anomalous Netlogon traffic patterns from non-DC source addresses; authentication failures or domain trust errors immediately after suspicious network activity hits a domain controller.

Enable Netlogon debug logging: nltest /dbflag:0x2080ffff


9 INDICATORS OF COMPROMISE (IOCs)

IOCs Available: Partial - behavioral and signature IOCs are available; no specific infrastructure IOCs (IPs, domains, file hashes from attacker tooling) have been publicly released by CCB or any threat intelligence source as of June 2, 2026.

Network-Level IOCs
  • CLDAP SearchRequest (UDP 389) with "User" filter attribute > 100 bytes in length
  • CLDAP SearchRequest with NtVer value = 0x02 0x00 0x00 0x00 (bits 2-3 clear, non-EX path, inconsistent with legitimate DC locator clients)
  • Single-packet UDP 389 with no response (DC-side timeout = LSASS has crashed)
  • Anomalous RPC/SMB traffic to domain controllers from untrusted subnets or non-domain-member hosts
Host-Level IOCs

  • Unexpected domain controller reboots with no prior Windows Update or scheduled maintenance activity
  • Child processes of lsass.exe (e.g., cmd.exe, powershell.exe, rundll32.exe) - abnormal process lineage indicating potential post-DoS RCE follow-on

10 POST-EXPLOITATION DETAILS

Persistence Mechanisms
  • Golden Ticket creation using stolen krbtgt hash (valid for 10+ years by default)
  • New privileged domain accounts (Domain Admin, Enterprise Admin)
  • DCShadow attack to inject rogue DC configuration changes
  • Scheduled tasks or WMI subscriptions on DC systems
  • Skeleton Key malware injection into LSASS (if interactive access is achieved)
  • Group Policy Object (GPO) modification for persistent domain-wide backdoor deployment
Behavior Observed in Real Attacks

No specific post-exploitation behaviors have been publicly disclosed by CCB or other threat intelligence sources regarding the current in-wild exploitation campaigns. The following is inferred based on the vulnerability class and similar historical Netlogon-targeting attacks:

  • C2 Communication: If RCE is achieved, outbound beaconing from lsass.exe or newly spawned child processes to attacker infrastructure
  • Credential Harvesting: DCSync to pull all domain credentials without needing to access individual machines
  • Domain Persistence: krbtgt password hash extraction for Golden Ticket forgery

11 MITRE ATT&CK MAPPING

12 VULNERABILITY CHAINING OPPORTUNITIES

Can this be chained with other issues?: Yes

If full RCE is achieved against a domain controller, CVE-2026-41089 becomes a master key for the entire Active Directory forest. More commonly, it will be chained in a two-stage manner: DoS is used to destabilize the DC (causing authentication disruptions that may be blamed on infrastructure issues) while a simultaneous or follow-on attack exploits a separate vulnerability or misconfiguration to gain persistent access.

Related CVEs (SentinelOne vulnerability database, same vulnerability class)

Misconfigurations that Increase Risk
  • Flat network architecture - any internal host can reach DC on UDP 389 with no segmentation
  • Domain controllers directly exposed to the Internet or to DMZ networks with inbound UDP 389 access
  • No UDP 389 egress/ingress filtering on internal firewalls between zone boundaries
  • ESU-expired or EoL Windows Server versions (2008 R2, 2012) without 0patch micropatches
  • Inconsistent patch deployment across DCs - even one unpatched DC in a forest is sufficient for exploitation
  • DNS domain names with 50+ total character counts (prerequisite for reliable LSASS crash)
Example Attack Chain (external threat actor)

10. Attacker scans for UDP 389 (CLDAP) open on Internet-exposed or DMZ-accessible domain controllers

11. Sends a benign CLDAP ping to identify active DCs and collect DNS domain name length information

12. If DNS domain name is ≥50 characters, sends 130-char username overflow packet → LSASS crashes, DC reboots (~60 second authentication outage across the domain)

13. (if full RCE achieved instead of DoS): Spawns reverse shell from LSASS context with SYSTEM privileges → performs DCSync to extract krbtgt hash → forges Golden Ticket → achieves persistent, undetected forest-wide access

14. Deploys ransomware or backdoor via GPO across all domain-joined systems simultaneously

13 DETECTION & MONITORING

SIEM Rules / Queries

Splunk:

index=wineventlog source="WinEventLog:Application" EventID=1000 Process_Name="lsass.exe" Module_Name="netlogon.DLL" Exception_Code="0xc0000409"

| eval risk="CRITICAL - Possible CVE-2026-41089 exploitation"

Elastic / Lucene:

event.code:1000 AND process.name:lsass.exe AND winlog.event_data.ModuleName:*netlogon* AND winlog.event_data.ExceptionCode:0xc0000409

KQL (Microsoft Sentinel):

SecurityEvent | where EventID == 1000 | where CommandLine contains "lsass.exe" and CommandLine contains "netlogon.DLL" and CommandLine contains "0xc0000409"

Log Sources

  • Windows Application Event Log (Event ID 1000 - LSASS crash with netlogon.DLL module)
  • Windows System Event Log (DC reboot events, Service Control Manager events for Netlogon restart)
  • Network IDS/IPS logs (UDP 389 with oversized payload - see Suricata rules above)
  • Sysmon Event ID 1 (Process Creation) - any process spawned by lsass.exe
  • Sysmon Event ID 3 (Network Connection) - outbound connections from lsass.exe
  • Netlogon debug log (%windir%\debug\netlogon.log - enabled with nltest /dbflag:0x2080ffff)
  • RPC audit logs (if RPC filtering is configured on DCs)
  • DC authentication logs for anomalous NTLM or Kerberos failures immediately post-crash

Behavioral Indicators

  • Sudden, unexplained domain controller reboots during non-maintenance hours
  • Authentication failures spiking domain-wide lasting approximately 60 seconds and self-resolving (corresponding to DC reboot window)
  • CLDAP traffic with User attribute values > 30 characters originating from non-domain-member IPs
  • LSASS crash with exception 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN) - this specific exception code is almost exclusively associated with GS stack cookie violations, which are a strong indicator of buffer overflow exploitation
  • Outbound connections from LSASS process (visible in Sysmon or EDR process network telemetry) - not normal LSASS behavior


14 RISK ASSESSMENT

15 REMEDIATION RECOMMENDATIONS

Immediate Actions

15. Identify all domain controllers in your environment and verify patch status. On each DC, run:

wmic qfe get HotFixID | findstr KB5089549

Or check build numbers: Settings > About, target builds listed in the Affected Products section above.

16. Apply the May 2026 Patch Tuesday updates to ALL domain controllers simultaneously, not in a rolling fashion. As noted by the Automox CTO, a half-patched AD forest is not a defensible posture for a pre-auth DC vulnerability.

17. For ESU-covered legacy versions (Server 2012/2012 R2): Obtain and apply ESU patches via WSUS / Microsoft Update Catalog.

18. For EoL versions (Server 2008 R2): Apply 0patch micropatches from Acros Security immediately (one-instruction fix: mov edx, 0x40 halves the maximum username length, preventing overflow). Begin emergency migration planning.

19. Restrict UDP 389 inbound access to domain controllers at the network level. Only systems with a legitimate need to perform DC locator pings (domain-joined systems, management tools) should be able to reach DC CLDAP services. Block from Internet-facing addresses unconditionally.

20. Enable Netlogon debug logging on all DCs to capture evidence of any exploitation attempts that may have occurred before patching:

nltest /dbflag:0x2080ffff

21. Review DC event logs retroactively for Event ID 1000 with exception code 0xc0000409 and faulting module netlogon.DLL. Any such event on an unpatched DC should be treated as a possible exploitation incident and trigger IR procedures.

22. Deploy YARA rules against all DC netlogon.dll binaries to confirm patch status (see IOC section).

Long-Term Fixes

23.Implement a formal patch SLA policy specifically for domain controllers: pre-auth critical vulnerabilities should be patched within 24–72 hours of Patch Tuesday release, not the typical 30-day enterprise window.

24.Enforce network micro-segmentation so that no host outside a defined DC management subnet can communicate with domain controllers on LDAP (TCP/UDP 389), SMB (TCP 445), or Netlogon RPC ports. East-west communication to DCs should be explicitly allowed only for domain members and admin jump boxes.

25.Establish Tier 0 / PAW (Privileged Access Workstation) architecture for domain controller administration to reduce the blast radius of any future DC compromise.

26. Integrate CLDAP anomaly detection (long User attributes, non-standard NtVer values) into your SIEM or NDR platform as a permanent detection rule - not just for this CVE but as a general Netlogon abuse detection capability.

27. Plan and execute migration off Windows Server 2012/2012 R2 and especially 2008 R2. ESU and micropatch coverage is finite; these systems are a permanent liability in AD environments.

28. Conduct a periodic review of DNS domain name lengths for all forest domains. While long DNS names are a rare prerequisite, this is a configuration hygiene item worth documenting.

Security Best Practices
  • Zero Trust Architecture: Never assume that any host inside the perimeter is safe. Domain controllers should authenticate inbound connections before processing them, and network access to DC services should be treated as privileged.
  • Defense in Depth for LSASS: Enable Windows Credential Guard where possible to isolate credential material even from LSASS context. Enable Protected Process Light (PPL) for LSASS on domain controllers.
  • Active Directory Tiering: Ensure DC accounts and administrative access follows a strict tier model. Credential material from Tier 1 and Tier 2 systems should never be present on domain controllers (Tier 0).
  • Continuous Patch Compliance: Use tools like Microsoft Defender for Endpoint, Automox, Qualys, or Tenable to maintain real-time visibility into DC patch status and generate alerts when critical DCs fall out of compliance.
  • Incident Response Readiness: Any unexpected DC reboot should trigger an automatic IR investigation workflow. The 60-second authentication outage caused by this exploit is a very specific and detectable pattern - ensure your NOC/SOC has runbooks that treat unexpected DC reboots as potential security incidents, not just infrastructure issues