Between May and August 2026, Microsoft shipped fixes for four separate remote code execution vulnerabilities, each CVSS 9.8, each requiring zero authentication and zero user interaction, each sitting in a Windows service whose entire job is to answer network requests from hosts that haven’t proven who they are yet. Netlogon. DNS Client. DHCP Server. DNS Server. In order: May 12, May 12 (same day, different component), July 14, and August 11.

One of them — Netlogon, CVE-2026-41089 — was confirmed under active exploitation seventeen days after the patch, prompting a public warning from Belgium’s Centre for Cybersecurity. The other three haven’t been caught in the wild yet, as far as public reporting shows. That “yet” is doing a lot of work, because every one of these bugs is the same shape as the ones that produced WannaCry, NotPetya, and Zerologon, and the industry spent the back half of the last decade telling itself that shape was mostly behind it.

It isn’t. This piece walks through what actually happened in each of the four bugs, why they cluster the way they do, and — more usefully — gives you a rubric for spotting the next one before the “exploitation less likely” label on the advisory ages as badly as it did this time.

The cluster, bug by bug

CVE-2026-41089 — Netlogon, May 12. A stack-based buffer overflow in the Netlogon Remote Procedure Call service (MS-NRPC), reachable over \\PIPE\NETLOGON on SMB/445 or the Netlogon RPC endpoint on dynamic ports. The vulnerable handler processes a length-prefixed field during protocol negotiation — before any credential exchange completes — and trusts the caller-supplied length without validating it against the destination buffer. One crafted packet against a domain controller, and you’re executing as NT AUTHORITY\SYSTEM. From SYSTEM on a DC it’s a straight line to ntds.dit, the KRBTGT hash, and Golden Tickets that survive password rotations. Active exploitation confirmed May 29 — seventeen days from patch to confirmed in-the-wild use, on a bug class that requires no more sophistication than “send a slightly wrong length field.”

CVE-2026-41096 — DNS Client, same day. A heap-based buffer overflow in DNSAPI.dll, triggered not by a request the host sends out but by a response it receives back. Any position that can forge or inject a DNS answer — a rogue DHCP-pushed resolver, a compromised upstream recursor, cache poisoning, a hostile access point — can hand a Windows endpoint a malformed record that overflows a heap buffer during parsing. This one doesn’t need a server role. Every Windows host that resolves a hostname is in scope, which is to say every Windows host, full stop. It’s also invisible to network-layer inspection the moment DoH is in play, since Windows 11 defaults to encrypted DNS to several well-known resolvers.

CVE-2026-50518 — DHCP Server, July 14. A heap overflow in how the DHCP Server role parses inbound requests carrying domain-name data. DHCP is UDP/67, connectionless, and pre-authentication by protocol design — a client without any credentials is the entire use case. Microsoft rated exploitation “more likely,” and nine separate DHCP-related CVEs closed in the same release, which reads less like a one-off and more like a research team methodically working through a code path once they found the first crack in it.

CVE-2026-62878 — DNS Server, August 11. A stack-based buffer overflow in packet parsing, wormable by ZDI’s own characterization, on a role that is routinely internet-facing by design — recursive resolvers, secondary zones accepting external zone transfers, edge forwarders. It shipped alongside three companion DNS Server RCEs in the same release (an out-of-bounds write reachable from an adjacent network, a race condition, and a use-after-free), meaning an org that patches slowly has three fallback paths into the same service even after closing the headline bug.

Lay the four side by side and the pattern is not subtle: stack or heap memory corruption, in a service whose protocol contract requires it to process input from hosts that haven’t authenticated, discovered across a five-month span, in the four Windows components most directly descended from the SMB/RPC/DNS stack that produced EternalBlue, Zerologon, and SIGRed.

Why this isn’t coincidence

Two decades of exploit mitigation work — ASLR, DEP, stack cookies (/GS), Control Flow Guard, and now hardware-backed CET shadow stacks — genuinely raised the cost of turning a memory-safety bug into reliable code execution. What they didn’t do is remove the memory-unsafe code. Netlogon, the DNS stack, and DHCP Server are old C codebases sitting underneath protocols (MS-NRPC, DNS, DHCP) that were standardized before memory safety was a design constraint anyone took seriously, and they have not been rewritten in a memory-safe language — unlike, say, the parts of the Windows kernel Microsoft has been visibly and publicly porting to Rust since 2023. The mitigation stack makes each individual bug harder to weaponize into a fully reliable exploit chain across every build and patch level. It doesn’t make the bug not exist, and a wormable stack overflow with a CVSS of 9.8 doesn’t need to be reliable against every target — it needs to work often enough to be worth automating.

The second reason is architectural and can’t be patched away: these are the services Windows built to be reachable without authentication, because that’s the point of DNS resolution, DHCP lease assignment, and (for Netlogon specifically) the initial handshake before Kerberos or NTLM authentication is even negotiated. You cannot add an auth gate in front of “hand out an IP address to a device that has no credentials yet” without breaking DHCP. You cannot require a signed session before a DNS query without breaking DNS. The attack surface is not a misconfiguration to remediate — it’s the protocol’s job description. That’s precisely why bugs in this exact tier of components produced the worst self-propagating incidents in Windows’ history, and it’s why they’ll keep doing it.

The third reason is context, not cause: Microsoft’s Patch Tuesday volume climbed all year — from a prior record of 175 CVEs in October 2025 to 206 in June, then a record-breaking 570-plus in July, then 398 in August — a trend Microsoft’s own engineering leadership has attributed in part to AI-accelerated bug discovery on both the offensive research and internal-hardening sides. More bugs surfacing faster is a net win when it means more get fixed before exploitation. But it also means your vulnerability-management team is now triaging 15-30 “Critical” CVEs a month instead of 3-5, and a rubric built for the smaller number doesn’t scale to the bigger one. Somewhere in a 398-CVE release, a wormable pre-auth DNS Server bug is one bullet point among sixty-two Critical-rated fixes. That’s not a hypothetical — it’s exactly what happened in August.

The vendor-severity-label problem, again

Microsoft rated CVE-2026-62878’s real-world exploitation “less likely.” Microsoft rated CVE-2026-41089 the same tier of “not yet observed” at initial disclosure — and it was confirmed exploited within three weeks. This isn’t a knock on any individual analyst’s call; exploitability prediction at disclosure time is genuinely hard, and vendors have institutional incentive to avoid crying wolf on every 9.8. But if your patch-priority queue is ordered by the vendor’s own likelihood label rather than by the objective shape of the bug (unauthenticated + network + memory corruption + designed-to-be-reachable service), you will patch the wrong things first often enough for it to matter. Treat “exploitation less likely” as a prediction with a documented, recent track record of being wrong on exactly this bug class, not as a green light to deprioritize.

A rubric for the next one

You cannot manually read the CVE description of every Critical bug in a 400-item Patch Tuesday drop and reason your way to correct prioritization every month — the volume doesn’t allow it. What you can do is build an automated first-pass filter that flags anything matching this profile for same-day human review, regardless of the vendor’s assigned severity or exploitability guess:

1
2
3
4
5
6
7
8
9

FLAG IF:
  attack_vector == "network"
  AND privileges_required == "none"
  AND user_interaction == "none"
  AND cwe IN (CWE-121, CWE-122, CWE-787, CWE-416, CWE-190)   # stack/heap overflow, OOB write, UAF, integer overflow
  AND component IN (
      "dns server", "dns client", "dhcp server", "netlogon",
      "smb server", "rpc runtime", "ldap", "kerberos", "spooler"
  )

Every one of the four 2026 bugs above trips every clause of that filter. So would the next one, whatever component it lands in — this is a small, enumerable list of Windows services that are pre-auth-reachable by protocol design, and it doesn’t change much year to year. Feed your CVE ingestion pipeline (whatever pulls MSRC’s API, NVD, or a commercial feed) through this filter before your team looks at CVSS scores at all, and route matches to a 24-hour patch SLA independent of what “Exploitation Less Likely” says.

Detection while you’re still patching

Patch order matters, but the gap between disclosure and full fleet coverage is real, especially across domain controllers, branch DHCP servers, and endpoints that don’t all sit on the same patch ring. While that gap exists:

  • Instrument crash-restart loops on the specific binaries. A failed exploitation attempt against a stack or heap overflow overwhelmingly manifests as an access violation and service crash before it manifests as a successful compromise. Watch Windows Error Reporting and EDR process-crash telemetry specifically for svchost.exe hosting dnscache (DNS Client), dns.exe (DNS Server), dhcpserver.dll inside the DHCP service host, and netlogon.dll-related lsass/services.exe crashes. A repeated crash-restart cycle on any of these in the current exposure window is a signal worth an immediate page, not a routine health alert.
  • A minimal Sigma-style skeleton for the pattern:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

title: Repeated Crash of Core Network Service Process
logsource:
  product: windows
  service: application
detection:
  crash_event:
    EventID: 1000
    Application|contains:
      - 'svchost.exe'
      - 'dns.exe'
      - 'services.exe'
  faulting_module|contains:
      - 'dnsapi.dll'
      - 'dns.dll'
      - 'dhcpserver.dll'
      - 'netlogon.dll'
  timeframe: 1h
  condition: crash_event | count() by Computer > 2
level: high
  • Inventory before you assume you know your exposure. Run a fleet-wide query for hosts with the DNS Server or DHCP Server role installed, cross-referenced against network exposure (internet-facing, adjacent-segment-reachable, or internal-only). A one-liner across your CMDB or via Get-WindowsFeature DNS,DHCP -ComputerName $fleet in a domain-wide loop will surface roles nobody remembered were still running on a decommissioned-in-spirit box.
  • Restrict what you can’t patch immediately. Disable zone transfers to untrusted secondaries. Limit inbound DNS queries to known resolver/forwarder relationships. Scope DHCP relay and broadcast domains so guest and BYOD segments can’t reach production DHCP infrastructure. Firewall RPC dynamic ports and SMB/445 to known administrative subnets for Netlogon-adjacent exposure — there’s no way to fully compensating-control your way around a protocol that must accept unauthenticated input, but you can shrink the population of hosts that can reach it.
  • Rotate KRBTGT twice, with the prescribed delay, if a DC was reachable from an untrusted network during any Netlogon exposure window you can’t fully rule out. That’s the only way to invalidate Golden Tickets minted from a leaked hash, and it doesn’t get less true because the exploitation window has technically closed.

What actually changes the trend

Better mitigations buy time; they don’t end the pattern, because the pattern’s root cause is memory-unsafe code in protocols that must accept untrusted input. The structural fix is the same one Microsoft has been slow-walking in the kernel: rewrite the parsers in a memory-safe language, or at minimum fuzz them continuously with the same AI-accelerated tooling that’s driving the record CVE counts, so more of these bugs get found and fixed pre-release instead of in production. That work is underway but multi-year by nature, and it will not save your Patch Tuesday next month.

What will save next month is refusing to let vendor severity labels and rising CVE volume numb your triage process to a bug shape with a two-decade track record of producing the worst incidents in Windows history. Four for four in five months is not noise.

Takeaways

  • Treat the profile, not the label. Unauthenticated + network vector + memory corruption + a protocol that’s pre-auth-reachable by design = 24-hour patch SLA, regardless of what “Exploitation Less Likely” says on the advisory.
  • Patch order: DCs and DNS/DHCP roles first, every cycle, ahead of the rest of the cumulative rollout — these four bugs prove the cost of getting that order wrong.
  • Build the automated filter now. At 200-600 CVEs a month, manual triage of every Critical bug doesn’t scale. A CWE + attack-vector + component filter does.
  • Instrument crash-restart loops on dns.exe, dnsapi.dll, dhcpserver.dll, and netlogon.dll as a canary for failed exploitation attempts during the patch gap.
  • Segment what you can’t patch instantly — zone-transfer restrictions, DHCP relay scoping, RPC/SMB port ACLs — none of it eliminates the exposure, but it shrinks the population of hosts that can reach it.
  • Rotate KRBTGT twice if you have any reason to suspect a DC was exposed to an untrusted network during a Netlogon-class exposure window.

Sources: Security Affairs — Microsoft Patch Tuesday for August 2026 Fixed a Zero-Day and Wormable RCE, Zero Day Initiative — The August 2026 Security Update Review, BleepingComputer — Critical Windows Netlogon RCE flaw now exploited in attacks, Help Net Security — Windows Netlogon RCE exploited, domain controllers at risk (CVE-2026-41089), Zero Day Initiative — The July 2026 Security Update Review, Talos Intelligence — Microsoft Patch Tuesday for July 2026, Dark Reading — Blame AI: Patch Tuesday Hits Record 206 CVEs, The Record — Microsoft’s massive Patch Tuesday releases continue as AI reshapes bug discovery.