🔑 IAM

Windows DHCP Rogue Server Attacks: NAC and DHCP Guard Controls Against CVE-2026-44815

CVE-2026-44815 in the Windows DHCP Client enables SYSTEM-level RCE via a rogue DHCP server on the same broadcast domain. DHCP Snooping (DHCP Guard) on enterprise switches is the primary compensating control while patching proceeds, but its effectiveness depends on consistent enforcement across all access-layer switches and correct handling of edge cases like DHCP relay configurations.

4 min read
#dhcp#cve-2026-44815#rogue-server#nac#network-access-control#dhcp-snooping#switching#802-1x#enterprise-network#2026

CVE-2026-44815, the Windows DHCP Client stack buffer overflow exploitable via rogue DHCP server response, requires any attacker on the same Layer 2 broadcast domain (VLAN) as a Windows victim to be able to send DHCP offer packets. DHCP Snooping — a switching feature that blocks DHCP server responses from all ports except designated uplinks — is the primary compensating control for this vulnerability class.

How DHCP Snooping Works

DHCP Snooping (called DHCP Guard on some switch platforms) enforces a trusted/untrusted port model:

  • Trusted ports: DHCP server responses are permitted. Set on uplink ports pointing toward the legitimate DHCP server (typically the uplink to the distribution layer or the specific server port if the DHCP server is on the same switch)
  • Untrusted ports: DHCP server responses are dropped. Set on all access ports where end devices (workstations, laptops, phones, IoT) connect

With DHCP Snooping enabled, a device connected to an untrusted port cannot successfully send a DHCP offer response — the switch drops it before it reaches Windows clients on adjacent ports. CVE-2026-44815 exploitation via a rogue device on an untrusted port is blocked at the switching layer.

Enabling DHCP Snooping: Platform-Specific Configuration

Cisco Catalyst switches:

ip dhcp snooping
ip dhcp snooping vlan 10,20,30,40  ! List all user VLANs
!
interface GigabitEthernet1/0/1
 ip dhcp snooping trust              ! Uplink to distribution — trusted
!
interface range GigabitEthernet1/0/2-48
 ! Access ports are untrusted by default when snooping is enabled
 ! No additional configuration required for untrusted behaviour

HP/Aruba switches:

dhcp-snooping
dhcp-snooping vlan 10 20 30 40
!
interface 1        ! Uplink — trusted
 dhcp-snooping trust

Juniper EX series:

set vlans USERS-VLAN dhcp-trusted-server
set interfaces ge-0/0/0 unit 0 family ethernet-switching dhcp-trusted  ! Uplink

Arista EOS:

ip dhcp snooping
ip dhcp snooping vlan 10,20,30
!
interface Ethernet1  ! Uplink
 ip dhcp snooping trust

Edge Cases and Common Deployment Errors

Error 1: Missing VLAN listing: DHCP Snooping must be explicitly enabled per VLAN. Enabling it globally without specifying VLANs does not protect those VLANs. Verify that all user VLANs — including guest VLANs, wireless VLANs, printer VLANs, and IoT VLANs — are included.

Error 2: DHCP relay misconfiguration: In environments where DHCP relay (IP helper) is used to forward DHCP requests from one VLAN to a DHCP server in another VLAN, the relay agent IP must be trusted. If DHCP Snooping drops legitimate DHCP relay traffic, clients lose IP address assignment. Ensure the DHCP relay interface is on a trusted port.

Error 3: Wireless access point DHCP: Wireless access points connected to access ports receive DHCP snooping enforcement like any other device. If the AP itself is a DHCP server for a captive portal or hotspot VLAN, configure that port as trusted for the AP’s management VLAN while leaving the wireless client VLAN protected.

Error 4: Insufficient coverage: DHCP Snooping on the access layer is ineffective if the attacker’s rogue DHCP server is on a different network segment that is routed to the victim VLAN. A compromised server in the data centre VLAN can send DHCP offers to a user VLAN if inter-VLAN routing permits broadcast forwarding. DHCP Snooping should be configured at every Layer 2 boundary, not just on access-layer switches.

802.1X Network Access Control as Complementary Control

DHCP Snooping prevents rogue DHCP from untrusted ports, but it does not prevent an attacker from physically connecting a rogue device to an access port in the first place. 802.1X port-based authentication prevents unauthorised devices from connecting to switchports:

With 802.1X enforced on access ports, a rogue device (laptop brought in by an attacker, compromised IoT device) cannot connect to the network until it authenticates via a certificate or credential. An unauthenticated port falls into a restricted VLAN with no network access.

802.1X + DHCP Snooping together provide:

  • Prevention of rogue device connection (802.1X)
  • Prevention of rogue DHCP from connected devices (DHCP Snooping)

For organisations with both controls in place, CVE-2026-44815 via physical rogue device is effectively blocked without requiring immediate endpoint patching. Note: credential-based lateral movement (a compromised legitimate device that responds to DHCP) is not blocked by either control — it requires patching.

Patch Remains Mandatory

DHCP Snooping and 802.1X are compensating controls — they reduce the exploitation surface but do not replace the patch. CVE-2026-44815 remains exploitable via:

  • A compromised legitimate device on the network (bypasses 802.1X because the device is authenticated)
  • A compromised switch or router that has trusted port status (bypasses DHCP Snooping)
  • Any network segment without DHCP Snooping configured

Apply the June 2026 Windows cumulative update to all Windows endpoints as the definitive remediation.

Share this article