CVE-2018-0173

What it actually does

Incomplete input validation of encapsulated DHCPv4 option 82 data in DHCPOFFER responses allows an unauthenticated remote attacker to trigger a device reload.

Why it matters to the business

Successful exploitation produces immediate denial of service on affected network devices, interrupting routing, switching, and DHCP relay services until manual recovery; the vulnerability is listed in CISA KEV with a 2022 remediation deadline, indicating confirmed active exploitation and requiring urgent attention across large Cisco IOS/IOS-XE deployments.

How an attack unfolds

An attacker sends a crafted DHCPv4 packet containing malicious encapsulated option 82 information toward an affected device; the device forwards the packet to a DHCP server and, upon receiving the server's DHCPOFFER reply, processes the malformed option 82 data, triggering an error that forces a device reload and creates a persistent DoS condition. Exploitation has been observed in the wild against Cisco infrastructure.

How to fix it

Upgrade all affected Cisco IOS and IOS-XE installations to the fixed releases published in Cisco security advisory CSCvg62754; where immediate patching is not possible, apply network segmentation and ACLs to restrict DHCP traffic to trusted servers only.

How to confirm the fix worked

Compare running software versions against the fixed releases listed in the Cisco advisory; confirm absence of the vulnerability by testing DHCP relay functionality with crafted option 82 packets in a lab environment and monitoring for reloads.

Typical attack path

1. Identify exposed Cisco IOS or IOS-XE devices acting as DHCP relays
2. Craft a DHCPv4 packet with malformed encapsulated option 82 data
3. Send the packet to the relay device, which forwards it to a legitimate DHCP server
4. Receive and process the server's DHCPOFFER response containing the malicious option 82
5. Trigger device reload resulting in denial of service

How to detect it

Search router and switch logs for unexpected reloads or crashes occurring shortly after DHCP relay activity; examine DHCP server logs for anomalous DHCPOFFER responses containing option 82 data; review NetFlow or packet captures for unusual DHCPv4 traffic patterns directed at relay agents.

What your security team should do

• Prioritize patching of all internet-facing and core infrastructure devices listed in the KEV catalog
• Implement DHCP traffic filtering at network edges to limit exposure until patches are applied
• Monitor device logs and crash reports for unexpected reloads correlated with DHCP activity
• Review and update incident response plans to account for rapid recovery of reloaded routers and switches