One CERT says it's exploited, Microsoft says it isn't, and you patch anyway

The headline writes itself: critical Netlogon RCE, CVSS 9.8, actively exploited, patch now. That’s the read most people will take away from the past week, and it lands them in roughly the right place by accident. The patch is correct. The reasoning underneath the headline is the part worth slowing down on.

Here’s the situation in plain terms. On Friday, May 29, the Centre for Cybersecurity Belgium (CCB) posted that CVE-2026-41089 in Windows Netlogon is “now actively exploited in the wild” and told customers to patch as quickly as possible. The following Monday, BleepingComputer reported that Microsoft “does not currently have any evidence to support” the claim, while still recommending the May updates. The flaw is absent from CISA’s KEV catalog (verified against the catalog feed, version 2026.06.01), and its EPSS score reads around 0.00095, roughly the 26th percentile. One named authority says it’s being exploited. The vendor says it has no corroborating evidence. Two independent quantitative signals read near zero.

The instinct is to treat that as a question you have to resolve before you act. It isn’t, and the more interesting detail is why.

What the alarm is actually about

The exploitation claim is the part of this story everyone is arguing over, which means it’s the part doing the least work. Strip it out entirely and the prioritization doesn’t move.

NVD describes CVE-2026-41089 as a stack-based buffer overflow in Windows Netlogon that “allows an unauthorized attacker to execute code over a network.” The 9.8 score decodes from the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which is the worst common shape an enterprise bug takes: network-reachable, low complexity, no privileges, no user interaction, full impact on confidentiality, integrity, and availability. Netlogon runs as SYSTEM, so successful exploitation means SYSTEM-level code execution on whatever machine answered the request.

The machine that answers Netlogon requests is your domain controller. That’s the whole point of the service. MS-NRPC handles domain authentication and secure-channel setup, so a DC must expose it, by design, to hosts that don’t yet have credentials. SYSTEM on a DC is not “one server is down.” It’s NTDS.dit, DCSync, forged Kerberos tickets, and forest-wide persistence. For the common single-forest, single-domain shop without tiered DC isolation, that’s the identity infrastructure for the entire organization.

That’s the read that matters, and notice what it didn’t require: nobody had to be exploiting it yet. A pre-authentication RCE that yields SYSTEM on a domain controller is a patch-now item on the strength of what it is. The CCB warning and Microsoft’s pushback are a sideshow to the actual decision.

The pattern: the alarm runs ahead of the evidence

Set the technical severity aside and look at the shape of the disclosure itself, because that’s where the pattern lives.

A bug gets disclosed and patched quietly, with no exploitation flag. Just over two weeks later a single national CERT publishes an in-the-wild warning citing “trusted partners,” with no IOCs, no victim names, no methodology, and no technical artifacts. The vendor, asked directly, declines to corroborate. The catalogs and the scoring models haven’t moved. Coverage compresses the gap into “actively exploited,” and the nuance evaporates on the way to your inbox.

This is the recurring failure mode of vulnerability triage, and it cuts both ways. Treat every unconfirmed CERT warning as gospel and you thrash your change calendar on rumor. Wait for KEV and EPSS to catch up before you act and you’ve outsourced your risk judgment to feeds that lag real-world activity by design. EPSS is a probability estimate that hasn’t yet absorbed the CCB warning and will likely move; KEV is a curated list with a confirmation bar, not a real-time exploitation sensor. Neither absence is evidence that nothing is happening. It’s evidence that nobody has published proof yet.

So the disagreement isn’t noise to be filtered out. It’s the signal. When a CERT says exploited and the vendor says no evidence and the models read zero, the honest interpretation is “exploitation is unconfirmed, severity is not.” Those are two separate facts, and only one of them is contested. The triage error is letting the contested fact override the settled one in either direction.

The evidence, and the precedent that should make you patch faster

Two pieces of context tighten the case. The first is who found it. Microsoft found the bug internally, credited it to its own WARP team, and published and patched the CVE together on May 12, 2026, with no exploitation flag at disclosure. That’s the calm baseline the CCB warning later disrupted, and it’s consistent with Microsoft’s “no evidence” position rather than at odds with it.

The second is Netlogon’s history, which is the real reason a working sysadmin should not wait on this one. CVE-2026-41089 is the latest entry in a six-year lineage of MS-NRPC bugs, and the repetition is structural. The marquee precedent is Zerologon (CVE-2020-1472, CVSS 10.0), severe enough that CISA issued Emergency Directive 20-04 giving federal agencies days to patch. It recurred with CVE-2022-38023, a Netlogon RPC elevation-of-privilege bug, and again with CVE-2025-49716, a Netlogon RPC hardening fix shipped last year.

The useful distinction: every prior marquee Netlogon bug was an authentication-logic or cryptographic flaw, fixed with phased enforcement modes and registry toggles to avoid breaking legacy non-Windows clients. CVE-2026-41089 is a different class. It’s plain memory corruption, which is why this one is a straight overflow patch with no enforcement dance and no registry step. The throughline is what should make you uneasy: each time Microsoft hardens one corner of MS-NRPC, the crypto, the signing, the access checks, a different corner of a large legacy protocol surface produces the next CVE. A reader who patched Zerologon in 2020 is patching the same service, for a structurally different reason, in 2026. When that service has this track record and Microsoft’s own threat researchers are the ones quietly finding the bugs, the gap between disclosure and a public proof-of-concept is something to close on your terms, not the attacker’s.

What this means for prioritization

The decision is narrower and more urgent than the headline suggests, both at once.

Narrower, because the urgent fleet is your domain controllers, not your entire Windows Server estate. Netlogon binaries ship everywhere, but the vulnerable handling path is exercised on the DC role. A member server on the same OS isn’t the target. That’s a small, well-defined list of the highest-value boxes you run, which is convenient operationally even if it’s the opposite of comforting strategically.

More urgent, because of how a half-patched forest behaves. This is a fleet-wide call, not a rolling one: every DC belongs in the same maintenance window, because a forest with some DCs patched and some exposed isn’t a defensible state against a pre-auth bug, only a slower path to the same compromise. Per Help Net Security, Automox’s Jason Kikta put it bluntly: a half-patched forest isn’t a defensible state against a pre-auth DC bug. The May cumulative update is the only real fix; there’s no official Microsoft workaround for a DC that can’t take it. The only stopgap is the network hygiene you should already have, restricting which hosts can reach DCs on Netlogon RPC ports and keeping user VLANs, guest networks, and DMZs off that surface. That’s defense in depth, not a substitute for the update.

One caution that costs nothing to honor. Don’t trust a third-party KB list for this. Coverage spans Windows Server 2016 through 2025, but the secondary trackers disagree on the exact KB for the Server 2022 builds, and at least one cited KB pair couldn’t be traced to a Microsoft source at all. The KB for each installed build should come straight from the Microsoft Update Catalog or the Security Update Guide, not from a tracker that aggregated it secondhand.

What to watch

The exploitation question is still open, and that’s fine. Two things would close it. The first is independent confirmation: a second government or vendor authority corroborating the CCB, or the CVE landing on CISA’s KEV catalog with a remediation deadline. Either one converts “patch on severity” into “patch on a clock,” and the EPSS score will move when it does. The second is a confirmed public proof-of-concept from a named, reputable source. Patch-diffing and root-cause work on a bug this severe reportedly tend to start fast, and the precise MS-NRPC trigger isn’t public yet, which is the only thing currently keeping a weaponized exploit off the open market.

None of that changes what you do this week. It changes how loud the next headline will be. A pre-auth SYSTEM RCE on a domain controller was always going to win its slot in the queue. The argument over whether it’s been used yet is the kind of thing you read about after your DCs are already patched, not before.

That gap, between the alarm and the action it should actually trigger, is the part PatchDay Alert exists to close: the daily read that tells you which bug jumps the queue on its own merits, before a CERT tweet has to tell you twice.