CVE-2026-56159 is a critical remote-code-execution vulnerability in the Windows DHCP Server service that can be triggered over a network without authentication or user interaction. Administrators running Microsoft DHCP should deploy the July 14, 2026 security updates promptly, because a successful attack could give an intruder code execution on infrastructure responsible for assigning network configurations to clients.
Microsoft disclosed the flaw through the Microsoft Security Response Center as part of its July 2026 security release. The National Vulnerability Database describes the underlying defect as a heap-based buffer overflow and records Microsoft’s maximum-impact CVSS 3.1 score of 9.8 out of 10.
The vector is unusually direct: network access, low attack complexity, no privileges, and no action from an administrator or end user. Microsoft’s scoring also indicates that successful exploitation could produce a complete loss of confidentiality, integrity, and availability on the affected system.
CVE-2026-56159 is classified as CWE-122, a heap-based buffer overflow. These flaws occur when software writes more data into a heap allocation than it can safely hold, potentially corrupting adjacent memory and redirecting program execution.
Microsoft’s concise description says an unauthorized attacker can exploit the Windows DHCP Server over a network. The public record does not yet provide packet-level details, identify a particular DHCP message or option, or explain the exact malformed input required to reach the vulnerable code.
That limited disclosure is intentional security hygiene while organizations patch. It also means administrators should not assume that filtering one obscure DHCP option, changing a scope setting, or disabling a secondary DHCP feature will provide equivalent protection.
DHCP servers occupy a sensitive position in Windows networks. They commonly communicate with large numbers of unmanaged and partially trusted devices, maintain authorization and lease databases, and may integrate with Active Directory and DNS dynamic updates. A compromise could therefore become a staging point for credential theft, service disruption, persistence, or attacks against other systems.
The vulnerability’s network rating does not automatically mean every Windows DHCP server is reachable from the public internet. In most enterprise deployments, DHCP traffic remains within internal network segments and is relayed between subnets by routers or switches.
That distinction reduces exposure to arbitrary internet attackers, but it does not make the issue low priority. A malicious device connected to an office, campus, industrial, guest, or poorly segmented network could potentially occupy the position needed to send traffic toward the service. DHCP relay configurations may also extend the effective attack surface beyond the server’s local broadcast domain.
Microsoft has not described CVE-2026-56159 as wormable. The available evidence supports treating it as remotely reachable and potentially automatable, but not as proof that exploitation can spread autonomously from server to server.
Server Core does not avoid the vulnerability. Microsoft explicitly lists Core installations of Windows Server 2012, 2012 R2, 2016, 2019, and 2025 where applicable, reinforcing that the flaw sits in the service rather than the graphical management environment.
Windows Server 2012 and Windows Server 2012 R2 require particular scrutiny because their normal support ended in October 2023. Organizations still operating them generally need applicable Extended Security Updates to continue receiving security fixes. Installing a July 2026 cumulative update on newer servers does not compensate for an unlicensed or otherwise unpatched legacy DHCP node left active elsewhere in the environment.
Administrators should inventory more than the DHCP servers documented in architecture diagrams. Disaster-recovery systems, branch-office appliances, lab domains, migration remnants, and authorized standby partners can continue running the service long after their original role has been forgotten.
Useful checks include reviewing the DHCP Server role in Server Manager, querying installed Windows features through PowerShell, checking whether the
Organizations using DHCP failover should patch and restart one partner at a time, verify that the remaining server is serving leases correctly, and then update the second node. Administrators should examine failover state, scope health, lease activity, DNS registration, and relevant DHCP Server event logs before declaring the maintenance complete.
The same caution applies to split-scope deployments and clustered or virtualized infrastructure. A successful Windows Update status is not enough if scopes remain inactive, failover relationships become degraded, or relay agents still point to an unavailable address.
Where the July update cannot be installed immediately, network controls can reduce exposure. Access-control lists should permit DHCP and relay traffic only from expected client networks and trusted relay addresses. Unnecessary routes to management, guest, lab, and wireless segments should be removed, and the service should be disabled on machines that do not need to provide DHCP.
Those measures are temporary risk reduction, not a replacement for the security update. The public advisory does not provide a configuration workaround that eliminates the vulnerable memory-processing path while preserving normal service.
Security teams should also monitor DHCP hosts for unexpected service crashes, restarts, child processes, memory-corruption events, and unusual inbound traffic. Because technical exploit details are not public, defenders should avoid relying on a single packet signature as their primary control.
That is useful context, but it should not be mistaken for a grace period. A confirmed heap overflow in a network-facing Windows service, combined with a 9.8 CVSS score and no authentication requirement, presents the kind of target that vulnerability researchers and criminal operators are likely to examine quickly after patches become available.
The released updates can also help attackers compare vulnerable and corrected binaries to identify the changed code. That patch-diffing window makes the first days after disclosure especially important for organizations whose internal networks contain unmanaged devices or whose DHCP servers accept relayed traffic from many locations.
The practical milestone is straightforward: every active Windows DHCP Server should be moved to its July 2026 fixed build, rebooted where required, and tested for lease and failover health. Until that inventory reaches zero vulnerable servers, CVE-2026-56159 remains a direct route from network traffic to one of the services keeping the Windows estate online.
Microsoft disclosed the flaw through the Microsoft Security Response Center as part of its July 2026 security release. The National Vulnerability Database describes the underlying defect as a heap-based buffer overflow and records Microsoft’s maximum-impact CVSS 3.1 score of 9.8 out of 10.
The vector is unusually direct: network access, low attack complexity, no privileges, and no action from an administrator or end user. Microsoft’s scoring also indicates that successful exploitation could produce a complete loss of confidentiality, integrity, and availability on the affected system.
The DHCP Role Turns a Memory Bug Into an Infrastructure Risk
CVE-2026-56159 is classified as CWE-122, a heap-based buffer overflow. These flaws occur when software writes more data into a heap allocation than it can safely hold, potentially corrupting adjacent memory and redirecting program execution.Microsoft’s concise description says an unauthorized attacker can exploit the Windows DHCP Server over a network. The public record does not yet provide packet-level details, identify a particular DHCP message or option, or explain the exact malformed input required to reach the vulnerable code.
That limited disclosure is intentional security hygiene while organizations patch. It also means administrators should not assume that filtering one obscure DHCP option, changing a scope setting, or disabling a secondary DHCP feature will provide equivalent protection.
DHCP servers occupy a sensitive position in Windows networks. They commonly communicate with large numbers of unmanaged and partially trusted devices, maintain authorization and lease databases, and may integrate with Active Directory and DNS dynamic updates. A compromise could therefore become a staging point for credential theft, service disruption, persistence, or attacks against other systems.
The vulnerability’s network rating does not automatically mean every Windows DHCP server is reachable from the public internet. In most enterprise deployments, DHCP traffic remains within internal network segments and is relayed between subnets by routers or switches.
That distinction reduces exposure to arbitrary internet attackers, but it does not make the issue low priority. A malicious device connected to an office, campus, industrial, guest, or poorly segmented network could potentially occupy the position needed to send traffic toward the service. DHCP relay configurations may also extend the effective attack surface beyond the server’s local broadcast domain.
Microsoft has not described CVE-2026-56159 as wormable. The available evidence supports treating it as remotely reachable and potentially automatable, but not as proof that exploitation can spread autonomously from server to server.
Supported Servers From 2012 Through 2025 Need Attention
Microsoft’s affected-product data spans multiple Windows Server generations, including Server Core installations. Systems below the listed fixed build levels remain vulnerable:- Windows Server 2012 is affected below build 6.2.9200.26226.
- Windows Server 2012 R2 is affected below build 6.3.9600.23291.
- Windows Server 2016 is affected below build 10.0.14393.9339.
- Windows Server 2019 is affected below build 10.0.17763.9020.
- Windows Server 2022 is affected below build 10.0.20348.5386.
- Windows Server 2025 is affected below build 10.0.26100.33158.
Server Core does not avoid the vulnerability. Microsoft explicitly lists Core installations of Windows Server 2012, 2012 R2, 2016, 2019, and 2025 where applicable, reinforcing that the flaw sits in the service rather than the graphical management environment.
Windows Server 2012 and Windows Server 2012 R2 require particular scrutiny because their normal support ended in October 2023. Organizations still operating them generally need applicable Extended Security Updates to continue receiving security fixes. Installing a July 2026 cumulative update on newer servers does not compensate for an unlicensed or otherwise unpatched legacy DHCP node left active elsewhere in the environment.
Administrators should inventory more than the DHCP servers documented in architecture diagrams. Disaster-recovery systems, branch-office appliances, lab domains, migration remnants, and authorized standby partners can continue running the service long after their original role has been forgotten.
Useful checks include reviewing the DHCP Server role in Server Manager, querying installed Windows features through PowerShell, checking whether the
DHCPServer service is present and running, and comparing winver, systeminfo, or PowerShell build output against the fixed versions. Configuration-management platforms should validate the resulting OS build rather than recording only that an update installation command completed.Patch the Partners Without Breaking Address Assignment
DHCP is a high-availability dependency, so immediate remediation still requires sequencing. Rebooting every DHCP server simultaneously can interrupt lease allocation and renewal, particularly for clients approaching renewal deadlines or devices joining the network for the first time.Organizations using DHCP failover should patch and restart one partner at a time, verify that the remaining server is serving leases correctly, and then update the second node. Administrators should examine failover state, scope health, lease activity, DNS registration, and relevant DHCP Server event logs before declaring the maintenance complete.
The same caution applies to split-scope deployments and clustered or virtualized infrastructure. A successful Windows Update status is not enough if scopes remain inactive, failover relationships become degraded, or relay agents still point to an unavailable address.
Where the July update cannot be installed immediately, network controls can reduce exposure. Access-control lists should permit DHCP and relay traffic only from expected client networks and trusted relay addresses. Unnecessary routes to management, guest, lab, and wireless segments should be removed, and the service should be disabled on machines that do not need to provide DHCP.
Those measures are temporary risk reduction, not a replacement for the security update. The public advisory does not provide a configuration workaround that eliminates the vulnerable memory-processing path while preserving normal service.
Security teams should also monitor DHCP hosts for unexpected service crashes, restarts, child processes, memory-corruption events, and unusual inbound traffic. Because technical exploit details are not public, defenders should avoid relying on a single packet signature as their primary control.
No Known Exploitation Does Not Lower the Patch Priority
CISA’s initial decision record for CVE-2026-56159 marked observed exploitation as “none” while assessing the vulnerability as automatable with total technical impact. As of July 15, 2026, the public record therefore does not establish active exploitation in the wild.That is useful context, but it should not be mistaken for a grace period. A confirmed heap overflow in a network-facing Windows service, combined with a 9.8 CVSS score and no authentication requirement, presents the kind of target that vulnerability researchers and criminal operators are likely to examine quickly after patches become available.
The released updates can also help attackers compare vulnerable and corrected binaries to identify the changed code. That patch-diffing window makes the first days after disclosure especially important for organizations whose internal networks contain unmanaged devices or whose DHCP servers accept relayed traffic from many locations.
The practical milestone is straightforward: every active Windows DHCP Server should be moved to its July 2026 fixed build, rebooted where required, and tested for lease and failover health. Until that inventory reaches zero vulnerable servers, CVE-2026-56159 remains a direct route from network traffic to one of the services keeping the Windows estate online.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
