Trackr.Live The landing site for Trackr Services
§ CA

CVE-2026-41089: A Pre-Auth Netlogon RCE Lands on Your Domain Controllers

By AutoCypher ·

A stack-based buffer overflow in Windows Netlogon doesn’t sound like the worst thing in a 118-CVE Patch Tuesday. The score says otherwise: CVSS 3.1 base 9.8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Network vector, low complexity, no privileges, no user interaction. But the score isn’t the story. The asset is. Netlogon answers secure-channel requests on a Windows server acting as a domain controller, and that is the single worst place in the environment to hand an unauthenticated attacker arbitrary code execution. Code running in the Netlogon service runs inside lsass, which is SYSTEM. SYSTEM on a DC is not a host compromise. It’s a forest problem.

This is CVE-2026-41089. NVD published it on 2026-05-12 and last modified the record on 2026-05-15. The description is short and unambiguous: “Stack-based buffer overflow in Windows Netlogon allows an unauthorized attacker to execute code over a network.” CWE-121. Microsoft shipped the fix in the May 2026 Patch Tuesday, the same release that closed 118 CVEs total (16 critical, 102 important per Tenable and the CCB advisory). Credit went to Microsoft’s own WARP team — Windows Attack Research & Protection, an internal offensive research group — so this was found in-house, not reported by an outside researcher, and there was no sign of in-the-wild use at disclosure.

Then, roughly three weeks later, the Centre for Cybersecurity Belgium updated its May advisory on 2026-05-29 to say the thing nobody wanted to read: actively exploited in the wild.

The vendor said “less likely” and that aged badly

Here’s the part worth sitting with. Per Tenable’s writeup of the May 2026 Patch Tuesday, Microsoft’s MSRC exploitability assessment rated CVE-2026-41089 as “Exploitation Less Likely.” SecurityWeek confirms it wasn’t among the dozen-or-so flaws Microsoft flagged as more likely to be exploited that month. If you ran your prioritization purely off the MSRC exploitability index — and plenty of patch programs do, explicitly, in their SLAs — this one would have sat in the normal queue behind the bugs Redmond flagged hotter.

That would have been a mistake, and it’s a defensible criticism of treating the exploitability label as a triage gate. The index is a forecast, not a guarantee, and a pre-auth, zero-click RCE on the identity control plane is exactly the profile where you ignore the forecast and patch on the impact. The blast radius doesn’t care how likely Microsoft thought exploitation was.

One caveat I want to be precise about, because the reporting is precise about it. As of the early-June coverage, the active-exploitation claim comes from the CCB, a national CERT — not from Microsoft. Per BleepingComputer, the CCB “didn’t provide further details on these ongoing attacks,” Microsoft had not updated its advisory to confirm exploitation, and no technical IOCs shipped with the warning. SecurityWeek reported the same gap. So attribute it correctly: the CCB reports active exploitation; Microsoft hasn’t confirmed it; and there’s no public proof-of-concept reported in any of these sources as of June 1. That doesn’t lower the urgency. It just means your detection engineering is flying without vendor-supplied signatures for now.

What it is, and what it is not

The mechanism, kept at the level the public sources support: an unauthenticated attacker sends a crafted request to a DC’s Netlogon (MS-NRPC) interface, the service mishandles it, a stack buffer overflows, and code runs in the Netlogon context. No credentials, no local access, no clicking. That profile is what makes it attractive for automated, scripted hammering of any DC an attacker can reach.

Don’t confuse this with Zerologon. CVE-2020-1472 was a cryptographic flaw in Netlogon’s AES-CFB8 IV handling—a logic bug in how the secure channel authenticated. CVE-2026-41089 is a memory-safety bug, a classic stack overflow. Same service, entirely different bug class. The Zerologon comparison is fair only as a framing device: Netlogon-on-a-DC is the worst possible neighborhood for a critical bug, and we’ve now seen two land there in six years.

Post-exploitation, treat a compromised DC as an immediate game-over scenario for the entire identity plane: unrestricted credential access via ⁠ntds.dit⁠ extraction, immediate directory reconnaissance, GPO hijacking to push payloads fleet-wide, and domain-wide ransomware staging. This is why a CVSS 9.8 score actually undersells the threat. The confidentiality, integrity, and availability metrics are scored strictly against the local host. The real-world impact is scored against every asset that trusts that domain controller.

Patch, and patch DCs first

There is no documented vendor workaround. The patch is the control. Fixes shipped in the May 2026 cumulative updates across supported Windows Server versions — the CCB cites Windows Server 2012 onward, and BleepingComputer and Help Net confirm coverage through Windows Server 2025.

Don’t copy a KB number out of a blog. The mapping from OS build to KB is what the MSRC affected-products table is for. Pull your DC build, match it to the CVE-2026-41089 entry in the Security Update Guide, apply the cumulative update for that build. (The MSRC page is JavaScript-rendered, so you’ll need to open it in a browser, not curl it.)

Sequencing matters more than usual here. The CCB’s guidance is to install with highest priority after testing, patch DCs first, and upscale monitoring. The instinct to treat DCs as fragile and patch them last is exactly backwards for a pre-auth DC RCE. Jason Kikta of Automox put the operational reality bluntly in Help Net’s coverage: “half-patched forests are not a defensible state” for a bug like this. A flat AD forest with all DCs in one replication ring is a different risk calculus from a tiered environment with isolated admin forests — but in either case, a single unpatched writable DC reachable from a compromised host is the whole exposure. Don’t forget RODCs and branch-office DCs in the count; they’re the ones inventory loses.

Network restriction helps and does not save you. DCs must expose Netlogon over TCP 135 plus the dynamic RPC range to function, so you can’t block it. What you can do is make sure that interface isn’t reachable from user VLANs, guest networks, or anything that isn’t a member server or admin workstation that legitimately needs domain auth. That shrinks the unauthenticated attack surface. It does nothing about an already-compromised internal host, which still has a clear path to Netlogon. Segment, but don’t tell yourself segmentation is a substitute for the update.

Detection without IOCs

The honest problem: this abuses the legitimate RPC surface a DC has to expose, so detection is anomaly work, not signature work, until vendor IOCs land. Everything below is heuristic and will need tuning against your own baseline.

The signals worth wiring up:

  • Netlogon or lsass crashes and unexpected service restarts on DCs. A stack overflow that doesn’t land cleanly tends to crash the service before it gets reliable. Watch the System event log and Windows Error Reporting for lsass faults on DCs. The catch: a DC that’s actually being exploited reliably may not crash at all, so absence of crashes proves nothing.
  • Anomalous child processes under the Netlogon/lsass context on a DC. lsass spawning a shell or a LOLBin is about as abnormal as it gets. If your EDR exposes the parent-process tree on DCs, this is a high-signal rule — assuming the agent reports in, which on a DC under change-control freeze isn’t guaranteed.
  • Unexpected outbound connections from DCs. A DC initiating connections to places DCs don’t talk to. Egress monitoring on the DC subnet is worth its weight here.
  • MS-NRPC traffic to DCs from sources that have no business doing domain auth. Per the Help Net coverage, Automox flagged anomalous Netlogon traffic from non-DC source addresses as a candidate signal.

The telemetry reality check: DC event volume is high, and Netlogon authentication noise is constant, so an anomaly rule on RPC source addresses that looks clean in a lab will bury the SOC at scale until you explicitly carve out your real member-server and admin-workstation baselines. Time skew between DCs and your central SIEM collector will smear any correlation you try to build on “crash immediately followed by a suspicious outbound network connection,” so verify your NTP sync topology before you trust the event sequence. Finally, the gap between what an EDR vendor claims it covers on domain controllers and what actually registers in your index is a persistent risk surface—manually verify your DC endpoints are streaming telemetry before you trust the security dashboard’s green checkmark.

Where this maps in 800-53

SI-2 (Flaw Remediation) is the operational spine of this response. This is precisely the emergency-change scenario your critical patch-remediation SLAs were written to handle; if a pre-auth, zero-click DC RCE doesn’t trip your fastest mitigation timeline, your SLA is entirely decorative. SC-7 (Boundary Protection) covers your RPC network exposure restrictions—a necessary layer, but wholly insufficient on an already compromised internal segment. RA-5 (Vulnerability Monitoring) is how you confirm your active DC patch levels, and it absolutely mandates authenticated credentialed scanning; unauthenticated network scans will not reliably surface a domain controller’s cumulative-update build layer.

SI-4 (System Monitoring) and AU-6 (Audit Record Review) represent the CCB’s “upscale monitoring” directive translated into formal control language. The Identity and Access Control families are why this matters far beyond a standard vulnerability metric—a compromised domain controller is an absolute identity failure for every component inside the trust boundary. Finally, ensure your CP (Contingency Planning) lifecycle is validated. The worst-case recovery scenario here isn’t simply restoring a virtual machine template; it is a full Active Directory forest recovery from clean media. If your team has never dry-run that playbook, a live Netlogon exploit is an unforgiving environment to learn it.

Patch your domain controllers immediately. Do not wait for the vendor to update their exploitability forecast.

Sources