CVE-2026-50683 Fix: Patch Windows DHCP Server Privilege Escalation

CVE-2026-50683 is a high-severity Windows DHCP Server privilege-escalation vulnerability that Microsoft fixed in its July 14, 2026 security updates. Despite some listings describing it as a Windows DHCP Client issue, Microsoft’s CVE data identifies the vulnerable component as DHCP Server and says exploitation could let an authorized attacker elevate privileges from an adjacent network.
Microsoft assigned the flaw a CVSS 3.1 base score of 8.0. The National Vulnerability Database, which received the record from Microsoft on July 14, classifies it as a heap-based buffer overflow under CWE-122 and lists affected releases stretching from Windows Server 2012 through Windows Server 2025.
That combination makes CVE-2026-50683 a priority for administrators responsible for DHCP infrastructure, particularly on networks where potentially untrusted devices share a local broadcast domain.

Infographic showing a Windows DHCP server, network segmentation, failover, monitoring, and a critical vulnerability alert.The Published Name Needs a Server-Side Correction​

The distinction between DHCP Client and DHCP Server is not cosmetic. Microsoft’s description, as reproduced by the NVD, states that a heap-based buffer overflow in Windows DHCP Server allows an authorized attacker to elevate privileges over an adjacent network.
The affected-product data reinforces that server-side framing. It includes Windows Server 2012, Server 2012 R2, Server 2016, Server 2019, Server 2022, and Server 2025, including several Server Core installations. Windows 10 versions 1607 and 1809 also appear in Microsoft’s affected-version record, but current Windows 11 client editions are not listed there.
Administrators should therefore use the CVE identifier—not an abbreviated headline—to match the vulnerability against scanners, update-management systems, and Microsoft’s Security Update Guide. Security products may temporarily ingest inconsistent titles while CVE records propagate between vendors and databases.
The relevant patched build thresholds published in Microsoft’s CVE record are:
  • Windows Server 2012 systems are affected below build 6.2.9200.26226.
  • Windows Server 2012 R2 systems are affected below build 6.3.9600.23291.
  • Windows Server 2016 and Windows 10 version 1607 are affected below build 10.0.14393.9339.
  • Windows Server 2019 and Windows 10 version 1809 are 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.
Those numbers provide a more reliable compliance check than simply confirming that Windows Update ran. A server can report a successful scan while remaining below the corrected build because of an installation failure, pending reboot, servicing issue, or update deferral.

Adjacent-Network Access Narrows—but Does Not Remove—the Risk​

Microsoft’s CVSS vector is AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. In operational terms, the attacker must have adjacent-network access and some existing authorization, but exploitation requires low complexity and no interaction from another user.
Adjacent network generally places the attack closer than an internet-wide remote exploit. An attacker would need an appropriate position on the same or otherwise logically adjacent network segment rather than being able to target any exposed Windows host across arbitrary routed networks.
That limitation matters, but enterprise networks routinely contain systems that should not be trusted merely because they obtained local connectivity. Contractor devices, compromised workstations, unmanaged endpoints, guest networks with faulty segmentation, branch-office equipment, and hostile virtual machines can all turn a local-network prerequisite into a realistic attack condition.
The low-complexity rating also means Microsoft does not expect exploitation to depend on an unusual race, a highly specific deployment, or extensive preparation. No user interaction is required, removing the need to persuade an administrator to open a file, follow a link, or approve a prompt.
Microsoft rated the possible confidentiality, integrity, and availability effects as high. Successful exploitation could therefore provide a path toward broad control of the affected system rather than producing only a limited service disruption.
The CVSS scope remains unchanged, meaning the vulnerable component and the impacted security authority are treated as part of the same security boundary. That is typical of a privilege-escalation flaw and distinguishes CVE-2026-50683 from a vulnerability whose exploitation directly crosses into a separate security authority.

The Evidence Is Vendor-Confirmed, but Exploit Detail Is Limited​

The vulnerability’s existence carries high confidence because Microsoft is the assigning CVE Numbering Authority and published the affected versions, weakness classification, severity vector, and update boundaries. This is not an unconfirmed third-party report based solely on suspected behavior.
At the same time, the publicly available technical description remains sparse. Microsoft identifies a heap-based buffer overflow but does not publicly document the malformed DHCP operation, affected code path, memory-corruption primitive, or a reproducible exploitation sequence.
That limits immediate attacker knowledge compared with a vulnerability accompanied by a detailed research paper or proof-of-concept exploit. It does not guarantee that exploit development will remain difficult, particularly once researchers begin comparing patched and unpatched Windows binaries.
CISA’s initial Stakeholder-Specific Vulnerability Categorization entry marked exploitation as “none,” automation as “no,” and technical impact as “total.” As of July 15, 2026, there was therefore no official indication in that record that CVE-2026-50683 was being exploited in the wild.
The “no” automation assessment should not be read as a permanent property of the flaw. It reflects CISA’s view based on the information available when the record was processed, before broader patch analysis and independent research had time to mature.

DHCP Servers Belong Near the Front of the July Queue​

For enterprise IT, the first task is to identify every Windows system providing DHCP services rather than relying only on an inventory of devices named or classified as DHCP servers. Temporary lab systems, failover partners, branch servers, and older infrastructure can easily escape a role-based query.
Administrators should install the July 14 security update appropriate to each affected Windows release, restart where required, and verify that the resulting OS build meets or exceeds Microsoft’s corrected threshold. DHCP failover pairs should be serviced in a controlled sequence so address allocation remains available while each node is updated.
Network controls remain useful while patch deployment is underway. Restricting access to DHCP infrastructure, enforcing VLAN boundaries, preventing guest or unmanaged segments from reaching server-management networks, and monitoring unexpected DHCP traffic can reduce exposure, although none replaces the update.
Older releases deserve particular attention. Windows Server 2012 and Server 2012 R2 require Extended Security Updates to continue receiving applicable fixes, while Windows 10 version 1607 and version 1809 remain supported only in specific long-term servicing or specialized configurations. An organization that finds one of these builds without an active servicing path has a lifecycle problem in addition to this CVE.
CVE-2026-50683 is not currently presented as an internet-scale, unauthenticated wormable vulnerability. Its position in a foundational network service, low attack complexity, lack of user interaction, and potential for total technical impact nevertheless argue against leaving DHCP servers unpatched until the end of a routine workstation cycle.
The immediate milestone is concrete: bring affected systems to at least builds 9200.26226, 9600.23291, 14393.9339, 17763.9020, 20348.5386, or 26100.33158 as appropriate, then confirm that DHCP service and failover behavior remain healthy after reboot.

References​

  1. Primary source: MSRC
    Published: 2026-07-14T07:00:00-07:00
 

Back
Top