CVE-2026-58627

What it actually does

CVE-2026-58627 is an unauthenticated network denial-of-service vulnerability in Windows DHCP Server caused by uncontrolled resource consumption. An attacker who can send traffic to the DHCP service can trigger excessive consumption of server resources, degrading or stopping the DHCP Server service and preventing it from reliably processing address lease, renewal, or configuration requests. The impact is availability-only: it does not provide code execution, privilege escalation, or data disclosure, but it can make DHCP unavailable on affected Windows Server and Windows versions running the DHCP Server role.

Why it matters to the business

Successful exploitation can disrupt network connectivity for users, endpoints, servers, phones, printers, and other devices that rely on DHCP for IP addressing. New devices may be unable to join the network, existing devices may fail to renew leases, and operational recovery may require service restarts or failover. Although this vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS likelihood, and has no reported mature exploit, the CVSS 7.5 availability impact makes it important for organizations that depend on Windows DHCP Server, especially in branch offices, campus networks, manufacturing networks, and environments with limited DHCP redundancy.

How an attack unfolds

An attacker first gains the ability to send DHCP traffic to an affected Windows DHCP Server, either from the same broadcast domain or through a DHCP relay path that forwards attacker-controlled requests. The attacker then sends specially crafted or high-volume DHCP messages intended to trigger the uncontrolled resource consumption condition in the DHCP service. Because exploitation requires no authentication, no user interaction, and low attack complexity, the primary barrier is network reachability to the DHCP service. If successful, the DHCP Server process or service consumes excessive CPU, memory, handles, sockets, or other resources, causing delayed responses, service instability, or service failure. The attacker’s objective is to deny address assignment and lease renewal, resulting in endpoint connectivity failures and broader network disruption until the service is patched, restarted, isolated, rate-limited, or failed over.

How to fix it

Apply the Microsoft security update that addresses CVE-2026-58627 for all affected systems running the DHCP Server role, including Windows Server 2012, 2016, 2019, 2022, and 2025, and any affected Windows 10 systems where DHCP Server components are present. No exact fixed build numbers were provided in the input, so use the relevant Microsoft Security Update Guide entry and install the July 2026 or later cumulative/security update applicable to each OS version. As mitigations, restrict DHCP service exposure to trusted network segments, block or tightly control inbound UDP/67 to DHCP servers from untrusted networks, review DHCP relay configurations, enable switch-level DHCP snooping where supported, apply rate limiting or storm-control on access networks, and ensure DHCP failover or redundant scopes are configured for critical networks. If active exploitation or instability is suspected, temporarily isolate abusive source ports or relay paths, restart the DHCP Server service only as a recovery measure, and preserve logs before remediation.

How to confirm the fix worked

Confirm that each affected host has the vendor security update installed and that its Windows build or patch level is equal to or newer than the Microsoft release that remediates this vulnerability. Verify that the DHCP Server role is only enabled where required and that UDP/67 is not reachable from untrusted networks. Test DHCP functionality after patching by requesting new leases and renewing existing leases from representative network segments. Review firewall, router, and DHCP relay ACLs to ensure only approved relay agents and client networks can reach the DHCP server. Monitor server performance counters and DHCP service health during controlled DHCP request testing to confirm the service remains stable. Validate that DHCP failover partners remain synchronized and that scope availability, lease issuance, and renewal behavior are normal.

Typical attack path

1. Identify a reachable Windows DHCP Server or a network segment where DHCP requests are relayed to one.
2. Send unauthenticated DHCP traffic to UDP port 67, typically from the local subnet or through a DHCP relay.
3. Use malformed, abnormal, or high-rate DHCP messages to trigger resource exhaustion in the Windows DHCP Server service.
4. Cause the DHCP Server service to become slow, unstable, or unavailable.
5. Disrupt IP address assignment and lease renewal for clients that depend on the affected DHCP scope.
6. Sustain or repeat the traffic to prolong the outage until filtering, rate limiting, failover, restart, or patching occurs.

How to detect it

Look for evidence of DHCP service instability, abnormal DHCP request volume, and resource exhaustion on affected Windows DHCP Servers. Relevant sources include Windows System logs, Microsoft-Windows-DHCP-Server operational and administrative logs, DHCP audit logs under %SystemRoot%\System32\Dhcp\, EDR process telemetry for the DHCP Server service host, firewall logs, switch DHCP snooping logs, router DHCP relay logs, NetFlow, and packet captures. Hunt for sustained spikes in DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, or malformed BOOTP/DHCP traffic to UDP/67; repeated service restarts or crashes of the DHCP Server service; high CPU, memory, handle, or thread counts associated with the DHCP service host; DHCP scope exhaustion without corresponding legitimate client growth; and large volumes of DHCP traffic from a single MAC address, a small set of MAC addresses, randomized MAC addresses, or an unexpected relay agent. Because this is a denial-of-service issue rather than a persistence or code-execution flaw, durable host artifacts may be limited; correlate network telemetry with service health degradation and client lease failures around the same time window.

• UDP/67
• UDP/68
• DHCPDISCOVER
• DHCPREQUEST
• DHCPDECLINE
• DHCPNACK
• Microsoft-Windows-DHCP-Server
• %SystemRoot%\System32\Dhcp\DhcpSrvLog-*.log
• C:\Windows\System32\Dhcp\DhcpSrvLog-*.log
• DHCPServer
• DHCP Server
• svchost.exe -k DHCPServer
• bootp.option.dhcp == 1
• bootp.option.dhcp == 3
• udp.port == 67 && bootp
• The DHCP Server service terminated unexpectedly
• The DHCP Server service entered the stopped state
• The DHCP Server service entered the running state

What your security team should do

• Prioritize patching Internet-adjacent, broadly reachable, or business-critical Windows DHCP Servers even though current EPSS is low and no known exploited status is reported.
• Inventory all Windows systems running the DHCP Server role across the affected Windows Server and Windows versions.
• Restrict DHCP traffic to expected client VLANs and approved DHCP relay agents; block UDP/67 from untrusted or unnecessary network paths.
• Enable or verify DHCP snooping, relay-agent controls, storm-control, and DHCP rate limiting on switches and network infrastructure where available.
• Review DHCP high availability, failover, backup, and recovery procedures for critical scopes before patch deployment.
• Add monitoring for DHCP Server service crashes, restarts, sustained high resource usage, lease exhaustion anomalies, and spikes in DHCPDISCOVER or DHCPREQUEST traffic.
• Investigate any recent unexplained DHCP outages, lease failures, or DHCP Server instability since publication on 2026-07-14.
• Retain DHCP audit logs, Windows event logs, packet captures, and network device logs when investigating suspected exploitation.