Two unauthenticated remote code execution vulnerabilities in Windows DHCP Server, tracked as CVE-2026-50518 and CVE-2026-56159, both landed with a CVSS score of 9.8 in Microsoft's July 2026 Patch Tuesday. That number is not decoration. A 9.8 on a service that every device on your network talks to before it does anything else — before authentication, before a security agent loads, before the machine even has an IP address to defend itself from — is about as bad as this job gets. If you run Windows DHCP Server anywhere in your environment, this is the patch you stop other work for.
Why Windows DHCP Server is such an attractive target in the first place
DHCP is one of those services that becomes invisible precisely because it works. It hands out IP addresses, DNS settings, gateway information, and vendor-specific configuration to every laptop, phone, printer, camera, VoIP handset, and access point that joins a network — automatically, silently, and by design without asking who's asking. That's the entire point of the protocol: a device that has nothing yet reaches out to DHCP first, before it has any other way to prove itself trustworthy or to be screened.
That property is exactly what makes a Windows DHCP Server RCE vulnerability so dangerous. The service has to be reachable by anything that might need an address, which usually means broad network exposure by default. It has to process requests from devices that haven't authenticated yet, because authentication itself typically depends on network connectivity DHCP just handed out. And because it's core infrastructure rather than a user-facing application, it's often under-monitored relative to its blast radius — nobody's watching DHCP traffic the way they watch a web application firewall or an EDR console. Compromise the DHCP server and, depending on what an attacker does next, you're not looking at one infected endpoint. You're looking at a service positioned to touch, or at minimum see, every device that requests an address on that network segment. That's the definition of high blast radius, and it's why these two CVEs deserve attention well beyond a routine line item in a patch summary.
Inside CVE-2026-50518: a heap overflow in domain name handling
CVE-2026-50518 is a heap-based buffer overflow, CWE-122, triggered when the DHCP server processes specially crafted network requests containing malicious domain name data. The root cause, per Microsoft's own description, is insufficient input size validation — the service allocates a buffer sized for what it expects, receives domain name data that doesn't respect that expectation, and the excess spills into adjacent heap memory. That's the textbook mechanism behind a huge share of memory corruption bugs: code trusts a length or format assumption about attacker-controlled input, and the actual input doesn't cooperate.
What makes it exploitable as remote code execution rather than just a crash is that heap overflows corrupt adjacent memory in ways that can be steered — overwriting heap metadata, function pointers, or other structures an attacker can influence enough to eventually redirect execution rather than simply take down the process. Microsoft's own advisory language and the CVSS vector confirm this isn't theoretical: no privileges required, no user interaction, low attack complexity, and a network attack vector. An attacker doesn't need a foothold on the target network, doesn't need a domain account, and doesn't need to wait for anyone to click anything. They send the packet, the server parses the malformed domain name data, and the overflow does the rest.
CVE-2026-56159 and the Option 43 problem
The second flaw, CVE-2026-56159, is also a heap-based buffer overflow, also CWE-122, also CVSS 9.8 — but it's triggered through a different feature: DHCP Option 43, the vendor-specific information field. Option 43 exists so a DHCP server can push configuration data to specific classes of hardware — VoIP phones that need to find their call manager, wireless access points that need to find their controller, and similar network devices that require more than a plain IP address and gateway to become functional. It's a common, legitimate feature in enterprise networks with any meaningful VoIP or Wi-Fi deployment.
The vulnerability triggers when a DHCP server configured to serve Option 43 data receives a specially crafted packet designed to abuse that code path, again resulting in memory corruption via a heap overflow. The attack surface here is narrower than CVE-2026-50518 in one specific sense — it requires the server to actually be configured to provide Option 43 data — but that's cold comfort in practice, because a lot of enterprise networks configure exactly that for their phone and access-point fleets. Same CVSS score, same unauthenticated network vector, same "no user interaction" profile, just a different code path getting hit with malformed input.
The worst combination a CVSS score can describe
It's worth pausing on why "unauthenticated, no user interaction, low attack complexity" is specifically the profile that should make a vulnerability management team move a patch to the top of the queue, ahead of things that might otherwise seem more urgent. Each of those three attributes removes a mitigating factor a defender would normally lean on.
Unauthenticated means there's no credential to protect, rotate, or monitor for anomalous use as a stopgap — the attacker doesn't need one. No user interaction means there's no phishing-awareness training, no "don't click that link" advisory, no human decision point that could interrupt the attack chain — the vulnerability doesn't need a person to make a mistake. Low attack complexity means the exploit doesn't depend on winning a race condition, guessing a memory layout, or chaining multiple unreliable steps together — it's not a bug that only works some of the time in a lab. Stack those three together on a service that's reachable by definition, and you get a vulnerability that a script can trigger reliably, remotely, against a target that has done nothing wrong other than exist on the network with the affected role installed. That's what a 9.8 actually represents, and it's why CVE-2026-50518 and CVE-2026-56159 aren't just "high severity" in the generic sense — they sit in the narrow band of bugs that security teams specifically build emergency-patch processes around.
Patch Tuesday at record scale: the operational problem hiding inside the good news
Here's the part that complicates an otherwise simple "patch immediately" instruction: these two DHCP flaws didn't land in isolation. They were part of Microsoft's July 2026 Patch Tuesday, which security industry coverage described as the largest such release on record — different outlets cited figures ranging from roughly 570 to 622 total CVEs addressed that month, depending on how each tracker counts related entries. Whatever the exact number, the order of magnitude alone makes this a genuinely unusual month, and it shipped alongside fixes for an actively exploited SharePoint zero-day that was already drawing attention on its own.
That scale is not just a headline stat — it's an operational problem for exactly the teams who most need to prioritize the DHCP fixes correctly. When a single update cycle contains hundreds of patches, triage becomes the bottleneck. Change-management windows don't expand to match the release size. Testing capacity doesn't scale with CVE count. And when a Patch Tuesday also includes an actively exploited zero-day getting most of the media attention, there's a real risk that two CVSS 9.8, no-exploitation-yet DHCP bugs get quietly deprioritized in favor of the flaw everyone's already talking about — even though "not yet exploited" against an unauthenticated, low-complexity RCE is frequently a short-lived state, not a stable one. As of July 15, 2026, there was no evidence of active exploitation of either DHCP flaw in the wild, but that window was never expected to stay open long, and a record-setting patch batch is precisely the condition under which a bug like this can slip through triage undetected until it's too late.
Practical takeaways
Patch priority should put CVE-2026-50518 and CVE-2026-56159 ahead of most of the rest of July's release for any server running the DHCP Server role, second only to whatever is confirmed as already under active exploitation — in this cycle, that means the SharePoint zero-day gets parallel urgency, but the DHCP fixes should not wait behind the routine backlog of the other few hundred CVEs in the batch. Inventory every DHCP server in your environment first, including secondary and failover DHCP instances that are easy to forget because they sit quietly in the background until the primary fails over to them.
Segment DHCP servers onto restricted network zones where only the broadcast and relay traffic they actually need can reach them, rather than leaving them flatly reachable from every subnet — DHCP has to be reachable by clients, but it doesn't need to be reachable from the entire enterprise network including guest Wi-Fi, IoT VLANs, and untrusted segments. Audit whether Option 43 is actually in use in your environment; if you're not pushing vendor-specific configuration to VoIP phones, wireless controllers, or similar devices, disable it, since CVE-2026-56159 specifically requires that feature to be configured and active to be exploitable. Increase monitoring on DHCP servers for the signs that matter here — unexpected process crashes or restarts of the DHCP service, unusual memory consumption patterns, and any spike in malformed or oversized DHCP option data in packet captures, since a heap overflow attempt that fails still tends to leave a crash or restart behind before an attacker gets the exploit reliable. And build your rollout so DHCP infrastructure gets tested and deployed in the first wave of this month's patch cycle, not the last, given how large a batch this is and how much internal contention there will be for testing time and change windows.
The uncomfortable truth about this month's Patch Tuesday is that its record-setting size is itself part of the risk. A vulnerability this severe, on a service this foundational, deserves to be the first thing patched — not a footnote buried in the largest update Microsoft has ever shipped in a single month.