Windows DHCP Server EUVD-2026-44141

Exploitation requires the target host to have the Windows DHCP Server role installed and running, and the attacker must be able to send DHCP protocol traffic to it (UDP 67) while holding some authorized/low-level privilege as indicated by PR:L - this is not an anonymous internet-wide attack. Realistic exploitation is further limited by AC:H: the double-free depends on winning a heap timing/grooming condition that is not reliably reproducible, meaning the attacker likely needs multiple attempts and favorable memory layout. Systems without the DHCP Server role enabled are not affected regardless of OS version.

The signals are moderate-to-serious but not emergency-tier. The CVSS base score is 7.5 (High) driven by network vector and complete C/I/A loss, but two metrics temper real-world risk: AC:H means the attacker must win a non-deterministic heap race or meet specific timing/memory conditions, and PR:L means some level of authorized/authenticated access is required rather than fully anonymous reach. No EPSS score was provided, there is no POC in the data, and the CVE is not in CISA KEV - so no evidence of active or automatable exploitation exists. Note a data inconsistency worth verifying: the description states 'execute code' and the vector sets C:H/I:H/A:H, yet the Tags field labels this 'Information Disclosure' - the code-execution framing should be treated as authoritative and the tag likely a feed artifact. Overall this is a legitimate patch-cycle priority for organizations running the DHCP Server role, but not a drop-everything item absent exploitation evidence.

An attacker with low-level authorized access to a network segment reachable by the DHCP service sends a carefully crafted sequence of DHCP messages designed to force the server to free the same internal buffer twice and then reclaim it with attacker-controlled data. By winning the resulting heap race (reflecting the AC:H complexity), the attacker corrupts allocator state to gain code execution in the DHCP Server process. No public POC is available at time of analysis, so a working exploit would require original heap-grooming research.