Windows DHCP Server EUVD-2026-73628

The target must have the Windows DHCP Server role installed, enabled, and reachable by the attacker's packets (UDP 67/DHCPv4 or 546-547/DHCPv6); exploitation requires no authentication, no user interaction, and works against default DHCP configurations once the role is running. Limiting factors: the DHCP Server role is not present on most Windows hosts (only on designated infrastructure servers), the attacker needs network reachability to the DHCP listener (often segmented to internal/client VLANs), and reliable memory-corruption exploitation against Windows' modern mitigations (ASLR, DEP, CFG) raises practical attack complexity above the CVSS AC:L rating.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8) describes a worst-case remote, unauthenticated, no-interaction RCE with total impact - the classic profile of a wormable infrastructure flaw. That said, reliable exploitation of a heap overflow in a hardened, ASLR/DEP/CFG-protected Windows service is typically non-trivial, so the real-world attack complexity is likely higher than the AC:L rating suggests; I would independently assess AC:H. EPSS is not provided and there is no KEV listing or public POC at time of analysis, so exploitation is currently theoretical rather than observed. Weighing these signals: this is a genuine high priority because DHCP servers are network-reachable core infrastructure and Microsoft rated it critical, but the absence of KEV/POC/EPSS data means it is a patch-urgently-but-not-yet-exploited item rather than an active-incident emergency. No conflicting signals were found between the CVSS vector and the description.

An attacker on a network segment that can reach the DHCP Server's listener crafts a malformed DHCP message with an oversized or malformed option field and sends it to the server, overflowing a heap buffer during parsing. With successful heap grooming, the corruption is steered into control-flow hijack, executing attacker code in the context of the DHCP service (typically a privileged system account), giving footholding on a core network service. No public POC is currently identified, so weaponization would require independent exploit development.