The Netlogon RCE got the headlines from Microsoft’s May 2026 Patch Tuesday, and rightly so. But there is a second 9.8 in the same drop that deserves its own fire drill: CVE-2026-41096, a heap-based buffer overflow in the Windows DNS Client. While Netlogon puts your domain controllers at risk, this one puts every Windows endpoint at risk — desktops, laptops, servers, IoT, anything that performs a DNS lookup, which is to say everything.

What the bug is

The flaw lives in DNSAPI.dll, the resolver library that every Windows process implicitly calls when it touches a hostname. When the client parses an incoming DNS response, it fails to correctly size the buffer used to store certain resource records. A specially crafted response — with overlong or malformed record data — triggers a heap-based buffer overflow. From there, an attacker who can shape the heap and corrupt the right object can hijack execution flow.

CVSS 9.8 attack vector network. No authentication. No user interaction. The triggering event is a DNS answer arriving on the wire, which means the victim process initiates the lookup itself in the course of doing perfectly ordinary work.

How an attacker delivers the payload

You do not need to be the authoritative server for a zone to land this. Any position that lets you forge or modify a DNS response works:

  • A rogue DNS server the host is configured to use (corporate VPN gone wrong, hostile DHCP on a coffee-shop Wi-Fi).
  • A compromised or misconfigured upstream recursor that returns crafted records.
  • Classic on-path MITM — open SSID, captive portal, ISP-level interception in hostile networks.
  • A compromised SOHO router rewriting answers in transit.
  • Cache poisoning against a downstream resolver, then waiting for the target to query.

And the payload sits inside DNS answer data, not inside a downloaded file. Signature-based AV engines that scan executables and scripts will not see it. If the resolver is using DNS-over-HTTPS (Windows 11 defaults to DoH for several well-known resolvers), the in-flight bytes are encrypted to your network IPS — your perimeter loses the only sensor that could have caught the malicious response.

What it gets the attacker

Code execution in the context of the process that issued the DNS query. For service binaries running as SYSTEM (DNS Client service itself, scheduled tasks, many service hosts), that is a full host compromise. For user-context processes, it is at least a foothold from which the usual local privilege-escalation chains take over. On servers, an attacker can pivot from a generic recursive lookup into kerberos pre-auth flows, Active Directory replication paths, or anywhere else DNS resolution is on the hot path.

There is no public proof-of-concept exploit as of this writing. That window will not stay open long — heap overflows in well-documented protocol parsers are reliably reverse-engineered from a patch diff, and the May 12 cumulative update is now public.

Who is affected

  • Windows 11, builds 23H2, 24H2, 25H2, 26H1, 22H3
  • Windows Server 2022, all builds
  • Windows Server 2025, all builds
  • Windows 10 LTSC and IoT Enterprise variants where DNS Client is in use

In practice, treat this as universal across the Windows fleet.

What to do right now

  1. Push the May 2026 cumulative update through WSUS, Intune, or whatever you use for endpoint patching. Treat servers and workstations the same — the bug does not care about role.
  2. Prefer trusted upstream resolvers and authenticated DNS. DNS-over-TLS or DoH to a reputable resolver removes the on-path attacker. It also blinds your IPS, so pair it with endpoint detection that has DNS visibility.
  3. Audit DHCP-pushed DNS servers on guest and BYOD networks. Hostile DHCP is the cheapest way to deliver this exploit to a roaming laptop.
  4. Watch for crashes in svchost.exe hosting dnscache. A failed exploit attempt typically lands as an access violation in DNSAPI.dll. WER reports and EDR process-crash telemetry are the canary.
  5. Segment IoT and OT hosts that cannot be patched. If a Windows IoT Enterprise device is doing DNS lookups on a flat network with internet egress, it is a soft target until the patch lands.

Why this one matters

Most critical Windows RCEs require a service to be reachable on a port the defender controls — SMB, RPC, HTTP. DNS is different. The vulnerable code path is exercised any time the host wants to resolve a name, which it does constantly and without the user’s knowledge. There is no firewall rule that meaningfully reduces the attack surface short of disabling DNS, and you cannot disable DNS. The only useful mitigation is the patch.

If your patch cadence treats client OSes as a lower priority than servers, this is the bug that breaks that habit.

Advisory: Microsoft Security Response Center — CVE-2026-41096 Analysis: Talos blog — Microsoft Patch Tuesday May 2026 Coverage: The Hacker News — Microsoft Patches 138 Vulnerabilities, Including DNS and Netlogon RCE Flaws