Two 9.8s in Windows DHCP Server: the unauthenticated heap-overflow RCEs hiding in July's Patch Tuesday

Two of the highest-severity bugs Microsoft fixed on July 14, 2026 never made the headlines. They were overshadowed by the month's actively-exploited zero-days (per Rapid7's Patch Tuesday roundup). But CVE-2026-50518 and CVE-2026-56159 are both CVSS 9.8, both unauthenticated, both network-reachable, and both sit in the same place: the Windows DHCP Server service — a role that quietly runs on domain controllers and infrastructure boxes across almost every Windows network on earth.

The same bug class, twice

Both CVEs carry an identical description and an identical weakness: a heap-based buffer overflow (CWE-122) in Windows DHCP Server that "allows an unauthorized attacker to execute code over a network." The CVSS vectors are byte-for-byte the same — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — meaning no credentials, no user click, low attack complexity, full compromise of confidentiality, integrity and availability.

So if the severity is identical, why treat them differently? Because impact (CVSS) and likelihood (EPSS) are separate signals — and here they diverge hard.

Why DHCP is a worst-case blast radius

DHCP is not a niche add-on. The DHCP Server role hands out IP configuration to every client on a segment, it typically runs on Windows Server, and in most environments it's co-located with Active Directory and DNS on the same domain controllers. A memory-corruption bug that runs code inside that service is therefore not "a DHCP outage" — it's remote code execution on the machine that authenticates your whole domain.

Who's affected

Both CVEs share the exact same affected surface — the DHCP Server role across supported (and some legacy) Windows Server builds, plus the LTSC Windows 10 editions that can carry it. Because the affected ranges are identical, one patch table covers both bugs: get the DHCP Server service to at least the build below.

Triage before a PoC lands

There's no vendor workaround for either CVE (has_workaround = false on both) — the fix is the July cumulative update. Until every DHCP server is patched, treat these as a race and shrink the exposure:

1. Patch the July 14 cumulative update on every server running the DHCP Server role, and confirm the OS/DHCP build meets the table above. There is no partial mitigation short of the update.
2. Inventory first. Enumerate authorized DHCP servers in the domain and the machines that actually run the role — you can only race for boxes you know exist.
3. Reduce reachability. DHCP is meant to be spoken to only from local segments via relay/IP-helper. Make sure UDP 67 to your DHCP servers is not reachable from user VLANs, guest networks, or anything internet-adjacent.
4. Separate roles where you can. The damage multiplier is DHCP sitting on a domain controller. New deployments should keep DHCP off DCs; existing ones should prioritise those hosts for patching.
5. Watch for crashes. Heap overflows frequently crash the target before they achieve reliable code execution — unexpected DHCP Server service restarts are worth an alert.

# List authorized DHCP servers in Active DirectoryGet-DhcpServerInDC# On a suspected DHCP host: confirm the role is installedGet-WindowsFeature -Name DHCP# Check the OS build — compare against the fixed-build table[System.Environment]::OSVersion.Version

The honest part: no public exploit — yet

In the cve.tools index, both CVEs read has_exploit: false: no Metasploit module, no Nuclei template, no public proof-of-concept. That is genuinely good news, and it's the reason this is a pre-exploit story rather than an incident-response one.

CVE, CVSS and EPSS data current as of 2026-07-31