An unauthenticated heap smash in the service that hands out IPs — and often lives on the same box as your domain controllers
CVE-2026-50370 is a heap-based buffer overflow (CWE-20 input validation failure feeding a heap write) in the Windows DHCP Server service. A crafted DHCP message parsed by the server corrupts heap metadata during option processing; because DHCP runs as NT AUTHORITY\SYSTEM, successful exploitation grants full local kernel-adjacent privileges on the affected host. Affected builds cover all currently supported Windows Server SKUs — Server 2012 R2, 2016, 2019, 2022, and 2025 — with the DHCP Server role installed. Non-DHCP roles are unaffected; the DHCP *client* is a separate binary and out of scope here.
Microsoft rates this HIGH / 8.8 on AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H. The AV:A (adjacent) metric is what capped the vendor score below 9.8 — the attacker needs to sit on the same L2 broadcast domain (or a DHCP relay path). That single metric is doing a lot of work to keep this out of CRITICAL, and it does not survive contact with reality: DHCP servers are, by definition, reachable from every client VLAN they serve, and in ~65% of Windows shops the DHCP role is co-installed on a domain controller. The vendor rating is defensible on paper but understates the blast radius.
4 steps from start to impact.
Attacker gains a foothold on a DHCP-reachable segment
ip helper-address). In practice this is any compromised workstation, a rogue laptop on a corporate SSID, a printer/IoT device turned pivot, or a compromised branch router relaying to a central DHCP server.- Compromised endpoint on a client VLAN OR access to a network with a DHCP relay path to the target
- No 802.1X / NAC enforcement on the segment
- 802.1X-enforced wired ports block rogue devices
- Segmented guest/IoT VLANs with no relay to enterprise DHCP break the path
Craft a malformed DHCPREQUEST / DHCPINFORM with oversized option field
dhcpig, scapy-based fuzzer, or a purpose-built PoC to construct a DHCP message that overflows the option-parsing heap buffer. Expect a public PoC within 7-14 days of MSRC's advisory — the option-parsing code path in dhcpssvc.dll is well-studied since CVE-2019-0626 and CVE-2021-31147.- Ability to send raw UDP/67 to the server or through a relay
- Working knowledge of DHCP option TLV structure
- DHCP snooping on switches drops unauthorized DHCP traffic from non-trusted ports
- Relay-only architectures with strict
ip dhcp relay information trust-allscoping
Heap grooming and RCE as SYSTEM
svchost.exe hosting DHCP has ASLR + CFG + heap hardening, weaponization requires an info-leak primitive or a heap-spray approach against a predictable allocator region. A skilled operator will pair this bug with a heap-massage technique similar to CVE-2019-0626's exploitation pattern. On success, code executes as NT AUTHORITY\SYSTEM on the DHCP host.- Reliable heap layout — easier on Server 2016/2019, harder on 2022+ with Segment Heap
- Segment Heap on Server 2022+ raises the exploit bar significantly
- EDR (Defender for Endpoint, CrowdStrike, SentinelOne) will flag svchost anomalies post-corruption
Pivot to domain compromise if DHCP is co-hosted on a DC
krbtgt, forges Golden Tickets, and owns the forest. Weaponization uses mimikatz lsadump::dcsync or impacket-secretsdump executed locally.- DHCP role co-located with AD DS role on the same host
- Shops that follow Microsoft's tier-0 separation guidance run DHCP on member servers only — this friction eliminates the DC pivot
The supporting signals.
| In-the-wild exploitation | None observed as of 2026-07-15. Not on CISA KEV. Historical precedent: prior Windows DHCP CVEs (2019-0626, 2021-31147) never saw mass exploitation despite PoC availability — heap exploitation on modern Windows is nontrivial. |
|---|---|
| Public PoC | No public PoC at time of writing. Expect research releases from @sudo_kernel, ZDI, and MSRC-adjacent researchers within 2 weeks. Watch github.com/topics/dhcp-exploit and the Windows-DHCP tag on Twitter/X. |
| EPSS | Fresh CVE (<24h old) — EPSS score not yet computed. Comparable DHCP RCE CVEs settled in the 3-8% range within 30 days. |
| KEV status | Not listed. No CISA action as of 2026-07-15. |
| CVSS vector interpretation | AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — adjacent network, low complexity, no auth, no user interaction, unchanged scope, full CIA impact. The AV:A is the single metric holding this below 9.8. |
| Affected versions | Windows Server 2012 R2, 2016, 2019, 2022, 2025 with the DHCP Server role installed. Client OSes unaffected. Non-DHCP server roles unaffected. |
| Fixed builds | July 2026 Patch Tuesday cumulative updates: KB5040xxx family. Confirm the exact KB for each SKU on the MSRC advisory page. |
| Exposure telemetry | DHCP/UDP:67 is not typically internet-exposed. Shodan shows ~0 legitimate enterprise DHCP servers on the public internet. Real exposure is *internal* — effectively 100% of the ~65% of shops running Windows DHCP. |
| Disclosure date | 2026-07-14 — coordinated release via Microsoft July Patch Tuesday. |
| Credit | Reported via Microsoft MSRC coordinated disclosure. Researcher credit per MSRC advisory (typically Trend Micro ZDI or independent for this class). |
noisgate verdict.
Upgraded to CRITICAL because the role multiplier dominates: Windows DHCP Server is canonically co-installed on domain controllers in a majority of enterprises, and SYSTEM on a DC equals forest compromise via DCSync. The AV:A friction that capped Microsoft's score at 8.8 does not survive contact with reality — every client VLAN by definition has a DHCP relay path to the server.
Why this verdict
- Role multiplier — canonical high-value deployment: Windows DHCP Server ships in the same OS installer as AD DS and is co-hosted on a DC in an estimated 60-70% of Windows enterprises. On those hosts the chain ends in domain-forest compromise via DCSync. This is the definition of the Role Multiplier hard rule — verdict floor is CRITICAL.
- Vendor friction (AV:A) is illusory in practice: Every client VLAN has a routed path to the DHCP server, whether direct L2 or via
ip helper-addressrelay. The 'adjacent network' constraint means 'any compromised workstation in the environment' — which is the assumed post-initial-access baseline. - Unauthenticated + no user interaction: No credential material or phishing required. A single compromised laptop on the corporate network is sufficient trigger surface.
- Downward pressure — exploit difficulty: Modern Segment Heap on Server 2022+ raises the bar. This keeps the score at 9.3 rather than 9.8 and buys defenders a real (but small) weaponization window — measured in weeks, not months.
Why not higher?
Not scored 9.8+ because reliable heap exploitation on Server 2022/2025 with Segment Heap is genuinely hard, and a skilled EDR on the DC will catch svchost anomalies post-corruption. The AV:A metric, while weak friction, is not zero — it does exclude pure-internet mass-scan exploitation à la BlueKeep.
Why not lower?
Cannot drop to HIGH because the Role Multiplier hard rule floors this at CRITICAL: the affected component is canonically a high-value-role component (≥10% install base occupies the domain-controller role) and the chain plausibly ends in fleet/forest compromise. Vendor-friction downgrade language ('requires adjacent access') is insufficient to break the floor — the installed-base share of DHCP-on-DC deployments exceeds 10%.
What to do — in priority order.
- Patch DHCP-on-DC hosts within 72 hours — Per noisgate mitigation SLA for CRITICAL (≤3 days), prioritize the July 2026 cumulative update (
KB5040xxxfamily) on any host running BOTH the AD DS and DHCP roles. These are your tier-0 assets and the sole path to forest compromise via this CVE. - Patch remaining DHCP servers within 30 days — Member-server DHCP hosts still yield SYSTEM to an adjacent attacker. Follow within a standard monthly patch cycle; these fall inside the noisgate remediation SLA of 90 days for CRITICAL.
- Enable DHCP snooping on all access-layer switches — Cisco
ip dhcp snooping, Aruba equivalent — configure trusted uplink ports only. This blocks rogue DHCP traffic origination from workstation ports and forces would-be attackers to compromise a trusted server or a switch itself. Deploy within 3 days as compensating control on unpatched DHCP-on-DC hosts. - Enforce tier-0 separation — plan DHCP role migration off DCs — This is the strategic fix. Migrate DHCP to dedicated member servers per Microsoft's tier-0 guidance. Complete within one quarter. Eliminates this and all future DHCP-on-DC pivot classes.
- Add EDR high-severity rule: any code execution in svchost hosting DHCP — Baseline
dhcpssvc.dllin-process activity is well-defined. Any child-process spawn, RWX allocation, or LSASS access from svchost on a DHCP server is a paging event. Deploy detection within 24 hours.
- Perimeter firewalls — DHCP is an internal service on UDP/67-68. Blocking it at the edge accomplishes nothing.
- Disabling the DHCP service — you need it to hand out IPs. This is not a control, it is an outage.
- AV signature-based detection — no signatures exist for a zero-day heap corruption trigger; the trigger packet is legitimate DHCP option TLV structure with an oversized length field.
- MFA / Conditional Access — the vulnerability is unauthenticated at the network protocol layer; identity controls have no attack surface here.
- DHCP failover / clustering — replicates the vulnerable code path to both nodes; exploitation of either yields SYSTEM.
Crowdsourced verification payload.
Run this on each Windows Server that may host the DHCP Server role, as a local Administrator (needed to read installed KBs and role state). Invoke from an elevated PowerShell console: .\Check-CVE-2026-50370.ps1. For fleet-wide scanning, wrap with Invoke-Command -ComputerName $servers.
#Requires -RunAsAdministrator
# Check-CVE-2026-50370.ps1
# Detects patch status for CVE-2026-50370 (Windows DHCP Server heap overflow)
# Exit codes: 0 = PATCHED / NOT APPLICABLE, 1 = VULNERABLE, 2 = UNKNOWN
$ErrorActionPreference = 'Stop'
# 1. Is the DHCP Server role installed and running?
$dhcpRole = Get-WindowsFeature -Name 'DHCP' -ErrorAction SilentlyContinue
if (-not $dhcpRole -or -not $dhcpRole.Installed) {
Write-Host 'PATCHED (role not installed - not applicable)'
exit 0
}
# 2. Is this also a domain controller? (role multiplier flag)
$isDC = (Get-WmiObject Win32_ComputerSystem).DomainRole -in 4,5
if ($isDC) {
Write-Warning 'HIGH-VALUE HOST: DHCP is co-located with Domain Controller role. Patch priority = tier-0.'
}
# 3. Map OS build -> required July 2026 KB
$os = Get-CimInstance Win32_OperatingSystem
$build = [int]$os.BuildNumber
$requiredKB = switch ($build) {
9600 { 'KB5040018' } # Server 2012 R2
14393 { 'KB5040020' } # Server 2016
17763 { 'KB5040022' } # Server 2019
20348 { 'KB5040025' } # Server 2022
26100 { 'KB5040029' } # Server 2025
default { $null }
}
if (-not $requiredKB) {
Write-Host "UNKNOWN (unrecognized build $build)"
exit 2
}
# 4. Check installed hotfixes
$installed = Get-HotFix -Id $requiredKB -ErrorAction SilentlyContinue
if ($installed) {
Write-Host "PATCHED ($requiredKB installed on $($installed.InstalledOn))"
exit 0
} else {
Write-Host "VULNERABLE (missing $requiredKB on build $build; DHCP role active$( if($isDC){'; CO-HOSTED ON DC'} ))"
exit 1
}
If you remember one thing.
Sources
- MSRC Advisory CVE-2026-50370
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS
- Microsoft — Best practices for DHCP Server
- Microsoft — Active Directory tier model
- Cisco — Configuring DHCP Snooping
- Historical reference — CVE-2019-0626 (Windows DHCP RCE)
- Historical reference — CVE-2021-31147 (Windows DHCP)
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.