Windows DHCP Client EUVD-2026-35751

The attacker must be able to deliver a malicious DHCP response that the victim's DHCP client will accept, which in practice requires positioning on the same Layer-2 broadcast domain as the target, control of an upstream DHCP relay, or a man-in-the-middle position on the path between the client and a legitimate DHCP server; the target must additionally have the Windows DHCP Client service enabled and be in the process of soliciting or renewing a lease. No authentication, user interaction, or non-default configuration is required per CVSS PR:N/UI:N, and the DHCP client is enabled by default on Windows installations. The principal limiting factor is therefore network adjacency rather than any software prerequisite - fully static-IP hosts with the DHCP Client service disabled, and hosts isolated from untrusted L2 segments, are not realistically reachable.

All signals point to a high-priority issue: the CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H vector confirms network-reachable, unauthenticated, no-user-interaction exploitation with full CIA impact, which is the worst-case profile for a client-side component embedded in every Windows endpoint and server. The vulnerability is not currently listed in CISA KEV and no public exploit identified at time of analysis, and EPSS data was not provided, but the combination of a critical CVSS, a Microsoft-coordinated disclosure, and a well-understood bug class (stack overflow in a network parser) historically attracts rapid weaponization. A practical caveat is that DHCP responses are normally received only from a server on the same broadcast domain or via a DHCP relay, so 'network' here effectively means adjacent-network in most realistic enterprise topologies - this nuance is not reflected in the AV:N rating and should temper raw-score comparisons. The MSRC reference URL was supplied but the linked advisory content, KEV status, exploitation telemetry, and EPSS percentile are not available in the provided data and should be verified directly.

An attacker on the same broadcast domain (for example a guest on a corporate Wi-Fi, a compromised IoT device, or a malicious DHCP relay) races or impersonates the legitimate DHCP server and responds to a victim's DHCPDISCOVER with a crafted DHCPOFFER/ACK containing an oversized option field that overflows the stack buffer in the Windows DHCP Client parser. The overflow corrupts a return address or exception handler, redirecting execution into attacker-controlled shellcode that runs in the DHCP client's privileged context, yielding code execution before the user has even logged in. No public exploit identified at time of analysis, so the scenario is theoretical but consistent with how prior DHCP client overflows (e.g., CVE-2019-0726) were demonstrated.