This is a link-following vulnerability in Windows DHCP Server where the service resolves filesystem references without validating they're not pointing outside intended boundaries. The CVSS 7.8 reflects significant impact, but the 'authorized attacker' qualifier in the disclosure obscures a critical question: can a low-privilege Windows user actually exploit this, or does it require administrative access?
The vulnerability likely stems from path-handling code in lease database or config file operations—legacy code paths that work correctly against regular files but never accounted for symlinks. Windows APIs like CreateFile follow symlinks by default, and developers rarely treat this as a security-relevant operation.
What you should verify:
-
Check DHCP service account permissions — Does the DHCP Server run under a service account with broad filesystem write access to lease databases or config directories? If so, standard users planting symlinks in any parent directory of those paths becomes a direct exploitation vector.
-
Audit filesystem ACLs on DHCP directories — Identify which folders the DHCP service accesses and verify whether standard users have write access to any parent directories where symlinks could be planted. This is the concrete step that determines whether this is a local LPE or requires elevated permissions.
-
Determine the trigger mechanism — The key unknown is whether exploitation requires local interactive access or if a standard-user process can trigger DHCP server link resolution remotely through lease renewals or RPC calls.
The EPSS score of 0.0038 probably assumes administrator-level access is needed. If this is exploitable from a standard user context, the actual risk is considerably higher than current scores suggest.
The patch will address this, but the deeper issue is that DHCP servers occupy a structurally central position in networks. Any filesystem misstep here doesn't just elevate local privileges—it positions the attacker as a man-in-the-middle for all DHCP traffic on the subnet, enabling client redirection, fingerprinting during boot, and potential PXE boot attacks. That's why this pattern keeps emerging across DHCP implementations: the blast radius of a compromise runs outward through the protocol itself, not just inward to the server.