HowToFixMe
● High · CVSS 8.6 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2018-0174: Improper input validation in Cisco IOS and IOS XE

⚡ At a glance
Severity8.6 (High)
Actively exploited?Yes, listed in CISA KEV (added 2022-03-03)
AffectedCisco IOS and IOS XE
Fixed inSee vendor advisory
Type (CWE)CWE-20: improper input validation

Exploitation status

CVE-2018-0174 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Cisco IOS Software and Cisco IOS XE Software Improper Input Validation Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: although a public exploit is not directly linked in this CVE’s primary references, its place on the CISA KEV catalog confirms working attack code is in active use in the wild, treat weaponization as certain and patch on an emergency timeline.

Authoritative references:

WARNING: This vulnerability is on the CISA Known Exploited Vulnerabilities catalog (added 2022-03-03). Federal civilian agencies must remediate by 2022-03-17. Treat it as active exploitation, not theoretical.

What is CVE-2018-0174?

CVE-2018-0174 is a denial-of-service (DoS) flaw in the DHCP option 82 encapsulation handling of Cisco IOS Software and Cisco IOS XE Software. It is not a remote code execution or privilege escalation bug. A successful attack forces the device to reload, dropping every packet it was switching or routing while it reboots. Cisco tracks it internally as bug ID CSCuh91645, and it was published in the bundled IOS/IOS XE DHCP advisory on 28 March 2018.

The root cause is classic CWE-20, improper input validation. When a Cisco device acts as a DHCP relay agent or processes relayed DHCPv4 traffic, it inspects the option 82 (DHCP relay agent information) field. The software performs incomplete validation of the option 82 data carried in those DHCPv4 packets. An unauthenticated, remote attacker who can get a crafted DHCPv4 packet to the affected device, no credentials and no user interaction required, can trip the parsing flaw and make the device reload. Repeated packets mean a repeatable crash, which is why this is rated availability-only but high: the CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H (base 8.6). Confidentiality and integrity impact are both None; the entire weight of the score is the availability hit, amplified by a changed scope because a relay-facing crash can knock out connectivity for everything downstream.

Practically, this matters on any IOS or IOS XE box sitting in the DHCP path: aggregation switches doing ip dhcp relay / ip helper-address, distribution-layer routers, or carrier edge devices that touch subscriber DHCP. If DHCP relay never runs on the device and option 82 insertion is disabled, your exposure is far lower, but the only authoritative way to know your build is or is not affected is the Cisco advisory and Software Checker, not a guess.

Identify which IOS / IOS XE build you run

This CVE only touches Cisco IOS and Cisco IOS XE. There is no Linux package, no Windows installer, and no other vendor involved, so check the device itself from its CLI:

# Cisco IOS / IOS XE. confirm the running train and image
show version | include (Version|IOS|image)

# See whether this box actually relays DHCP (the attack surface)
show running-config | include (ip helper-address|ip dhcp relay|dhcp.*option 82)

Take the train string from show version (for example 15.2(4)E or an IOS XE Version 16.x) and run it through the Cisco Software Checker linked in the advisory. Cisco did not publish a single global "fixed in X.Y" number for this bug; the first fixed release depends on your specific platform and feature train. Do not assume a fixed version, look yours up. If ip helper-address or DHCP relay appears in your config, treat the device as in-scope and prioritise it.

How to fix CVE-2018-0174

The fix is to upgrade to a Cisco IOS or IOS XE release that contains the patch for CSCuh91645. Because Cisco's fixed-release table is per-platform and per-train, the canonical source for your first-fixed build is the Cisco Software Checker and the advisory, not a hard-coded version on this page. The upgrade procedure itself is standard image replacement:

Upgrade Cisco IOS / IOS XE

! 1. Find your fixed release in the Cisco Software Checker (see advisory), then:
enable
show version | include Version
dir flash:                              ! confirm free space for the new image
copy running-config startup-config      ! save current config

! 2. Transfer the fixed image (SCP shown; TFTP/FTP/USB also valid)
copy scp: flash:
verify /md5 flash:.bin     ! match the MD5/SHA from cisco.com

! 3. Point the boot loader at the fixed image and reload
configure terminal
 no boot system
 boot system flash:.bin
 end
write memory
reload                                  ! schedule a maintenance window

For IOS XE platforms running in install mode, use the package workflow instead of boot system:

! IOS XE install-mode upgrade
copy scp: bootflash:
install add file bootflash:.bin activate commit
! the device reloads into the fixed package and commits it
show install summary

After the reload, verify the running version matches the fixed build you selected and confirm DHCP relay still works:

show version | include Version
show ip dhcp server statistics      ! relay/server counters incrementing again

If you can't patch immediately

There is no fixed-configuration workaround that fully removes the flaw, Cisco's advisory lists no workaround, so an upgrade is mandatory. What you can do is shrink the attack surface until the maintenance window lands. All of these are partial and must be reverted to a patched state.

Limit which DHCP traffic reaches the device

The trigger is a crafted DHCPv4 packet carrying malformed option 82 data hitting the relay path. If a device does not need to relay DHCP, remove the relay configuration; where it must relay, constrain the sources it trusts and the interfaces that accept bootps/bootpc (UDP 67/68).

! If this device does NOT need to relay DHCP, remove the helper entirely
configure terminal
interface 
 no ip helper-address 
end
write memory

! Where relay IS required, block DHCP from untrusted interfaces with an ACL
! (apply inbound on the interfaces facing untrusted clients)
ip access-list extended BLOCK-UNTRUSTED-DHCP
 deny  udp any any eq bootps
 deny  udp any any eq bootpc
 permit ip any any
interface 
 ip access-group BLOCK-UNTRUSTED-DHCP in
end
write memory

Pair this with DHCP snooping on access switches so only trusted ports forward DHCP server-side traffic, and keep your management plane locked down to a trusted subnet:

! Management-plane hardening (defence in depth, not a fix for this CVE)
configure terminal
ip access-list standard MGMT-ONLY
 permit 10.0.0.0 0.255.255.255
line vty 0 15
 access-class MGMT-ONLY in
end
write memory

Verify the fix landed

After the upgrade, confirm on the device itself, there is no host-side package or registry check for this, it lives entirely in IOS/IOS XE:

# Confirm the running image is the fixed release you selected
show version | include Version

# Confirm DHCP relay/server is healthy again after the reload
show ip dhcp server statistics
show running-config | include ip helper-address

Expected result: show version reports the fixed train you pulled from the Cisco Software Checker, the device stays up under normal DHCP load, and relay counters increment without unexpected reloads in show logging. Re-run your vulnerability scanner against the management IP to confirm it no longer flags CVE-2018-0174.

Frequently asked questions

Can this CVE be used to take control of my router or steal data?

No. CVE-2018-0174 is purely a denial-of-service bug. The CVSS vector is C:N/I:N/A:H, so confidentiality and integrity are unaffected, an attacker cannot read traffic, change configuration, or run code. The only outcome is forcing the device to reload, which drops connectivity while it reboots. That is still serious on a core or aggregation device, but it is not RCE.

Is my device affected if it does not run DHCP relay?

The flaw lives in how IOS/IOS XE validates option 82 data in DHCPv4 packets handled on the relay path. Devices doing ip helper-address / ip dhcp relay are the clear targets. If DHCP relay and option 82 handling are not configured, your practical exposure is much lower, but you should still confirm your exact train against the Cisco Software Checker rather than assuming you are clear.

What is the fixed version?

Cisco did not publish one global fixed version for CVE-2018-0174. The first fixed release depends on your platform and feature train, and the authoritative source is the Cisco Software Checker linked in the advisory (CSCuh91645). Look up the build reported by show version there and upgrade to the first fixed release it names for your platform.

Why is this on the CISA KEV list and what is my deadline?

CISA added CVE-2018-0174 to the Known Exploited Vulnerabilities catalog on 2022-03-03, confirming real-world exploitation. U.S. federal civilian agencies had to remediate by 2022-03-17 under Binding Operational Directive 22-01. Everyone else should treat that as a strong signal to patch on an emergency timeline rather than a routine one.

References

Written by Sai Kiran Pandrala on 2026-05-25. Always confirm against the vendor's advisory before applying changes in production.

Operational notes for IOS / IOS XE fleets

Because the trigger is a single crafted DHCPv4 packet, the highest-value devices to patch first are the ones in the DHCP relay path with the widest blast radius: distribution and aggregation switches running ip helper-address, and any carrier or campus edge box that relays subscriber DHCP. A reload on one of those takes down everything behind it, which is why the scope flag in the CVSS vector is Changed and the score climbs to 8.6 despite being availability-only.

Inventory across a fleet is straightforward to script: pull show version for the train and show running-config | include ip helper-address for the exposure flag from every device, then feed the train strings into the Cisco Software Checker in bulk rather than eyeballing them one by one. Group the results by first-fixed release so you can batch the upgrades into a small number of maintenance windows instead of touching every box individually.

When you schedule the reload, remember the device drops traffic during boot, so a relay-path switch needs a real maintenance window and, ideally, a redundant path that keeps DHCP flowing while one device reloads. Confirm the fix with show version against the build the Software Checker named, watch show logging for any further unexpected reloads, and re-scan the management IP so your vulnerability tooling stops flagging CVE-2018-0174.

Related weaknesses in the same component worth addressing at the same time:

People also ask

Can this CVE be used to take control of my router or steal data?

No. CVE-2018-0174 is purely a denial-of-service bug (CVSS C:N/I:N/A:H). An attacker cannot read traffic, change configuration, or run code, the only outcome is forcing the device to reload and drop connectivity while it reboots.

Is my device affected if it does not run DHCP relay?

The flaw is in option 82 validation on the DHCPv4 relay path, so devices doing ip helper-address / ip dhcp relay are the clear targets. If relay and option 82 handling are not configured, exposure is much lower, but still confirm your exact train in the Cisco Software Checker.

What is the fixed version?

Cisco published no single global fixed version. The first fixed release depends on your platform and feature train; look up the build from show version in the Cisco Software Checker (bug CSCuh91645) and upgrade to the first fixed release it names.

Why is this on the CISA KEV list and what is my deadline?

CISA added it on 2022-03-03, confirming real-world exploitation. U.S. federal civilian agencies had to remediate by 2022-03-17 under BOD 22-01. Everyone else should treat that as a reason to patch on an emergency timeline.