Microsoft’s July 14, 2026 security updates fix CVE-2026-58627, a high-severity Windows DHCP Server denial-of-service vulnerability that can be triggered remotely by an unauthenticated attacker. The immediate action for administrators is straightforward: identify every server running the DHCP Server role and bring it to the July servicing baseline before treating the month’s patch cycle as complete.
Microsoft’s Security Update Guide classifies the flaw as uncontrolled resource consumption, tracked as CWE-400. Its CVSS 3.1 score is 7.5, with a network attack vector, low complexity, no required privileges, no user interaction, and high availability impact. In practical terms, the published advisory describes an attacker who can send network traffic capable of exhausting resources and interrupting DHCP service—not someone gaining code execution, stealing data, or taking administrative control.
The National Vulnerability Database has published Microsoft’s record but has not yet completed its own enrichment. CISA’s accompanying SSVC data currently marks exploitation as “none,” while also judging the issue automatable with partial technical impact. That is useful prioritization input, not a reason to defer remediation: vendor-confirmed, unauthenticated network denial-of-service bugs in infrastructure services deserve a short patch window.
DHCP is not usually a glamorous target, but it is foundational. A server failure can prevent newly connected devices from obtaining addresses, disrupt lease renewals, strand Wi-Fi clients after roaming or reconnecting, and complicate recovery work precisely when IT teams need network access most.
The impact varies with the environment’s lease design and redundancy. A client with a valid existing lease may continue working for some time, while an endpoint that needs a fresh address, has just restarted, or has moved to a different VLAN may fail immediately. Short lease intervals, guest networks, manufacturing floors, classrooms, branch offices, and device-dense wireless deployments can therefore feel a DHCP outage much faster than a quiet server subnet.
The vulnerability is particularly important because the documented attack requires neither an authenticated Windows account nor user interaction. Administrators should not confuse “network reachable” with “internet exposed,” however. DHCP Server traffic is normally confined to local broadcast domains, routed relay paths, and trusted network segments rather than publicly reachable over the internet.
That constraint reduces indiscriminate exposure, but it does not eliminate risk. A malicious insider, compromised endpoint, rogue device connected to a poorly controlled VLAN, or attacker with foothold in a branch network may have the positioning needed to target a DHCP server. Networks that use DHCP relay also expand the operational relevance beyond the server’s directly attached subnet.
A conventional Windows workstation using DHCP as a client is not the target described by this advisory. The vulnerable component is Windows DHCP Server, so the first inventory task is to find authorized DHCP servers, including appliances or virtual machines that may have been deployed outside the standard server-management process.
Microsoft’s July 14 fixed-build boundaries are:
Windows Server 2012 and Windows Server 2012 R2 need special attention. Their inclusion in the vulnerability data does not mean every legacy deployment will receive the update automatically; organizations need the applicable Extended Security Updates coverage and servicing configuration. If a legacy DHCP server cannot receive the July update, that is an architecture problem as much as a patching problem.
The right deployment plan is normally a rolling one. Confirm the scope, failover relationship, split-scope configuration, relay addresses, lease-health status, and available capacity before beginning maintenance. Patch a secondary or standby node first where the design permits it, validate lease issuance and renewal from representative VLANs, then move through the remaining nodes without taking the whole address-assignment service offline.
Validation should extend beyond checking that the DHCP Server service reports “Running.” Test a new client lease, a lease renewal, a reservation, DHCP relay traffic from a remote subnet, and DNS dynamic updates if the environment uses integrated registration. Review DHCP audit logs and event logs for abnormal failures, database issues, failover state changes, or a surge in declined leases.
Organizations should also use the patch cycle to search for DHCP servers they did not know existed. A Windows Server with the role installed but no current configuration may be harmless; an active but unmanaged DHCP instance can create both availability and security trouble. Rogue DHCP detection on switches, DHCP snooping where appropriate, and accurate IP address management records all reduce the chance that an incident becomes an extended troubleshooting exercise.
Those measures are compensating controls. They cannot guarantee that malicious traffic from a legitimate local network position will be filtered, and they do not correct the resource-consumption flaw. Rate limiting may help preserve availability in some environments, but administrators should test carefully: indiscriminate limits can harm PXE boot, large Wi-Fi reconnect events, VDI startup storms, or disaster-recovery scenarios.
Monitoring also matters during the gap. Watch for abrupt DHCP service restarts, elevated CPU or memory consumption, unusual request volume, lease-processing delays, and spikes in client address-assignment failures. These signals are not proof of exploitation, but they can distinguish a normal connectivity complaint from a service-level availability event that requires containment.
Microsoft has confirmed the vulnerability’s existence, classification, affected version ranges, and corrected servicing boundaries. What is not public in the advisory is equally important: there are no packet-level details, proof-of-concept instructions, or vendor-confirmed reports of active exploitation. That limits certainty about exploitation mechanics, not the need to update.
For Windows administrators, CVE-2026-58627 belongs near the front of the July queue wherever DHCP is central to day-to-day connectivity. Patch the DHCP role hosts, verify the build rather than the deployment report alone, and test failover before an attacker—or an ordinary service failure—tests it for you.
Microsoft’s Security Update Guide classifies the flaw as uncontrolled resource consumption, tracked as CWE-400. Its CVSS 3.1 score is 7.5, with a network attack vector, low complexity, no required privileges, no user interaction, and high availability impact. In practical terms, the published advisory describes an attacker who can send network traffic capable of exhausting resources and interrupting DHCP service—not someone gaining code execution, stealing data, or taking administrative control.
The National Vulnerability Database has published Microsoft’s record but has not yet completed its own enrichment. CISA’s accompanying SSVC data currently marks exploitation as “none,” while also judging the issue automatable with partial technical impact. That is useful prioritization input, not a reason to defer remediation: vendor-confirmed, unauthenticated network denial-of-service bugs in infrastructure services deserve a short patch window.
DHCP Outages Become Endpoint Outages Quickly
DHCP is not usually a glamorous target, but it is foundational. A server failure can prevent newly connected devices from obtaining addresses, disrupt lease renewals, strand Wi-Fi clients after roaming or reconnecting, and complicate recovery work precisely when IT teams need network access most.The impact varies with the environment’s lease design and redundancy. A client with a valid existing lease may continue working for some time, while an endpoint that needs a fresh address, has just restarted, or has moved to a different VLAN may fail immediately. Short lease intervals, guest networks, manufacturing floors, classrooms, branch offices, and device-dense wireless deployments can therefore feel a DHCP outage much faster than a quiet server subnet.
The vulnerability is particularly important because the documented attack requires neither an authenticated Windows account nor user interaction. Administrators should not confuse “network reachable” with “internet exposed,” however. DHCP Server traffic is normally confined to local broadcast domains, routed relay paths, and trusted network segments rather than publicly reachable over the internet.
That constraint reduces indiscriminate exposure, but it does not eliminate risk. A malicious insider, compromised endpoint, rogue device connected to a poorly controlled VLAN, or attacker with foothold in a branch network may have the positioning needed to target a DHCP server. Networks that use DHCP relay also expand the operational relevance beyond the server’s directly attached subnet.
Patch the Servers That Actually Run the Role
Microsoft’s affected-product metadata spans Windows Server 2012 through Windows Server 2025, including Server Core installations. It also lists Windows 10 Version 1607 and Version 1809 packages, but the real exposure question is not whether a Windows device appears in a broad servicing list—it is whether it hosts the DHCP Server role.A conventional Windows workstation using DHCP as a client is not the target described by this advisory. The vulnerable component is Windows DHCP Server, so the first inventory task is to find authorized DHCP servers, including appliances or virtual machines that may have been deployed outside the standard server-management process.
Microsoft’s July 14 fixed-build boundaries are:
- Windows Server 2012 and Server Core: build 9200.26226.
- Windows Server 2012 R2 and Server Core: build 9600.23291.
- Windows Server 2016 and Server Core: build 14393.9339.
- Windows Server 2019 and Server Core: build 17763.9020.
- Windows Server 2022: build 20348.5386.
- Windows Server 2025 and Server Core: build 26100.33158.
Windows Server 2012 and Windows Server 2012 R2 need special attention. Their inclusion in the vulnerability data does not mean every legacy deployment will receive the update automatically; organizations need the applicable Extended Security Updates coverage and servicing configuration. If a legacy DHCP server cannot receive the July update, that is an architecture problem as much as a patching problem.
Keep DHCP Redundancy From Becoming a False Sense of Security
Failover is valuable, but it is not a patch. Two DHCP servers running the same vulnerable code can both be targeted, and an attacker may be able to repeat the denial-of-service condition as each node returns to service.The right deployment plan is normally a rolling one. Confirm the scope, failover relationship, split-scope configuration, relay addresses, lease-health status, and available capacity before beginning maintenance. Patch a secondary or standby node first where the design permits it, validate lease issuance and renewal from representative VLANs, then move through the remaining nodes without taking the whole address-assignment service offline.
Validation should extend beyond checking that the DHCP Server service reports “Running.” Test a new client lease, a lease renewal, a reservation, DHCP relay traffic from a remote subnet, and DNS dynamic updates if the environment uses integrated registration. Review DHCP audit logs and event logs for abnormal failures, database issues, failover state changes, or a surge in declined leases.
Organizations should also use the patch cycle to search for DHCP servers they did not know existed. A Windows Server with the role installed but no current configuration may be harmless; an active but unmanaged DHCP instance can create both availability and security trouble. Rogue DHCP detection on switches, DHCP snooping where appropriate, and accurate IP address management records all reduce the chance that an incident becomes an extended troubleshooting exercise.
Network Controls Buy Time, Not a Fix
When immediate maintenance is impossible, reduce who can send DHCP-related traffic toward the server and relay infrastructure. Segment untrusted client networks, limit access between VLANs to only approved DHCP relay paths, and review firewall rules that are broader than the topology requires.Those measures are compensating controls. They cannot guarantee that malicious traffic from a legitimate local network position will be filtered, and they do not correct the resource-consumption flaw. Rate limiting may help preserve availability in some environments, but administrators should test carefully: indiscriminate limits can harm PXE boot, large Wi-Fi reconnect events, VDI startup storms, or disaster-recovery scenarios.
Monitoring also matters during the gap. Watch for abrupt DHCP service restarts, elevated CPU or memory consumption, unusual request volume, lease-processing delays, and spikes in client address-assignment failures. These signals are not proof of exploitation, but they can distinguish a normal connectivity complaint from a service-level availability event that requires containment.
Microsoft has confirmed the vulnerability’s existence, classification, affected version ranges, and corrected servicing boundaries. What is not public in the advisory is equally important: there are no packet-level details, proof-of-concept instructions, or vendor-confirmed reports of active exploitation. That limits certainty about exploitation mechanics, not the need to update.
For Windows administrators, CVE-2026-58627 belongs near the front of the July queue wherever DHCP is central to day-to-day connectivity. Patch the DHCP role hosts, verify the build rather than the deployment report alone, and test failover before an attacker—or an ordinary service failure—tests it for you.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: tomshardware.com
Windows Server vulnerability can grant system privileges with just a malformed packet — domain controllers are being exploited in the wild | Tom's Hardware
System administrators, run the May 12 patch immediately if you haven't already.www.tomshardware.com - Official source: support.microsoft.com
July 14, 2026—KB5099536 (OS Build 26100.33158) | Microsoft Support
July 14, 2026—KB5099536 (OS Build 26100.33158)support.microsoft.com
