How to Fix CVE-2018-0173: Improper input validation in Cisco IOS and IOS XE
| Severity | 8.6 (High) |
|---|---|
| Actively exploited? | Yes, listed in CISA KEV (added 2022-03-03) |
| Affected | Cisco IOS and IOS XE |
| Fixed in | See vendor advisory |
| Type (CWE) | CWE-20: improper input validation |
Exploitation status
CVE-2018-0173 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Cisco IOS and 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), which makes remediation mandatory for U.S. federal civilian agencies under BOD 22-01. Treat it as active exploitation, not theoretical, and patch on an emergency timeline.
What is CVE-2018-0173?
CVE-2018-0173 is a denial-of-service vulnerability in the DHCP version 4 (DHCPv4) relay agent of Cisco IOS Software and Cisco IOS XE Software. The function that restores encapsulated option 82 information performs incomplete input validation on the data it receives in DHCPOFFER messages from a DHCPv4 server. Because that validation is incomplete (the root cause is CWE-20, improper input validation), a malformed option 82 field can trigger an error that reloads the device, producing a Relay Reply denial-of-service condition.
The attack path is indirect, which is what makes it easy to overlook. An unauthenticated, remote attacker sends a crafted DHCPv4 packet to the affected device. The device, acting as a DHCP relay, forwards that request to a real DHCPv4 server. When the server's response comes back and the device processes the encapsulated option 82 information in it, the parsing error occurs and the device reloads. Cisco tracks the defect as bug ID CSCvg62754 and assigned the CVSS 3.1 base score of 8.6 (High) with vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H. Note the impact profile: confidentiality and integrity are None, availability is High. This is purely a crash-and-reload bug, not remote code execution and not privilege escalation. The scope is Changed because the crafted packet enters through one security context (the relay-facing network) and the failure manifests in the device's control plane.
The practical consequence: a single crafted packet can take a router or switch offline, and if that device is an aggregation point, everything behind it loses connectivity until it finishes reloading. CISA added CVE-2018-0173 to its Known Exploited Vulnerabilities catalog on 2022-03-03, so this is not a theoretical concern.
Am I affected?
Exposure depends on whether the device runs an affected IOS or IOS XE build and acts as a DHCPv4 relay. Check the running version and the relay configuration directly on the device:
# Cisco IOS / IOS XE
show version | include Version
show running-config | include ip helper-address
If show running-config returns one or more ip helper-address lines, the device is configured as a DHCP relay and is in scope for this vector. The fixed build is release-specific, so the version string alone does not tell you whether you are patched. Take the exact version that show version reports and run it through the Cisco IOS Software Checker tied to advisory cisco-sa-20180328-dhcpr2 (linked in References) to get the first fixed release for your train.
How to fix CVE-2018-0173
The only complete fix is to upgrade to a Cisco IOS or IOS XE release that contains the patch. Cisco did not publish one universal fixed-version string for this CVE, the first fixed release differs per software train: so do not trust any page that quotes a single magic version number. Determine your fixed release from the Cisco Software Checker, then upgrade.
Step 1, Find your fixed release
- Open advisory
cisco-sa-20180328-dhcpr2(in References) and launch the embedded Cisco IOS Software Checker, or use the standalone checker at the Cisco Security Center. - Enter the exact output of
show version(for example, the IOS XE release such as16.6.xor the IOS train such as15.2(x)). - The checker returns whether your version is affected and the earliest fixed release for that train. Download that image from your Cisco account (a valid service contract is required).
Step 2. Upgrade the image
Back up the configuration, stage the fixed image, set it as the boot image, and reload during a maintenance window. The exact transfer commands vary slightly between classic IOS and IOS XE, but the sequence is the same:
# On the device, in privileged EXEC mode
enable
copy running-config startup-config
# Verify free flash space, then copy the fixed image
dir flash:
copy tftp://<tftp-server-ip>/<fixed-image>.bin flash:
# Verify image integrity before booting it
verify /md5 flash:<fixed-image>.bin
# Point the boot loader at the fixed image (IOS XE uses the install/bundle model;
# classic IOS uses boot system). Adjust to your platform's upgrade method.
configure terminal
boot system flash:<fixed-image>.bin
end
write memory
reload
After the reload completes, confirm the new build is running:
show version | include Version
Re-run the Software Checker against the new version string to confirm it is no longer flagged as affected.
If you can't patch immediately
Cisco's advisory lists no workaround for CVE-2018-0173, the fixed software is the remedy. The controls below reduce the attack surface but do not close the bug, so schedule the upgrade regardless.
- Trust only known DHCP servers. The crash is triggered by the relayed server response, so restricting which DHCP servers your relay forwards to and accepts replies from limits who can feed the device a malformed option 82 field. On Layer 2, enable DHCP snooping and mark only the legitimate server's port as trusted:
configure terminal ip dhcp snooping ip dhcp snooping vlan <vlan-list> interface <uplink-to-dhcp-server> ip dhcp snooping trust end write memory - Filter DHCP at the edge. Use an ACL on untrusted interfaces to drop DHCP (UDP 67/68) from anything other than your sanctioned DHCP infrastructure, so spoofed client requests cannot reach the relay path.
- Reconsider the relay itself. If a given device does not need to relay DHCP, remove the
ip helper-addressstatements that put it in scope.
None of these substitute for the patch. They only shrink the window of who can reach the vulnerable code path.
Frequently asked questions
Is CVE-2018-0173 remote code execution?
No. It is a denial-of-service flaw. A crafted DHCPv4 packet handled by the relay agent causes the affected device to reload. The CVSS 8.6 score reflects availability-only impact (A:H, with confidentiality and integrity both None): no data is read or altered, but the device drops offline until it finishes rebooting.
Which Cisco IOS or IOS XE version fixes CVE-2018-0173?
There is no single fixed version that covers every train. The first fixed release depends on your specific IOS or IOS XE software train. Enter your exact running version into the Cisco IOS Software Checker on advisory cisco-sa-20180328-dhcpr2 to get the correct fixed build for your platform.
Am I affected if I do not use DHCP relay?
The vulnerable code is the DHCPv4 relay agent that restores encapsulated option 82 information. A device with no ip helper-address configured is not relaying DHCPOFFER messages and is not exposed to this vector. Confirm your relay configuration before deprioritizing the upgrade.
Can I mitigate without upgrading?
There is no Cisco-documented workaround. You can lower exposure with DHCP snooping, trusted-server restrictions, and edge ACLs that limit which DHCP servers the relay will accept replies from, but only the upgrade removes the flaw.
References
- Official vendor advisory: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180328-dhcpr2
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2018-0173
- CISA KEV catalog entry: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- http://www.securityfocus.com/bid/103545
- https://ics-cert.us-cert.gov/advisories/ICSA-18-107-04
- https://www.tenable.com/security/research/tra-2018-06
- http://www.securitytracker.com/id/1040591
Related fixes
Other flaws in this area worth reviewing while you patch this one:
- How to Fix CVE-2018-0167: Buffer overflow in Cisco IOS, IOS XE, and IOS XR
- How to Fix CVE-2018-0175: Buffer overflow in Cisco IOS, IOS XE, and IOS XR
- How to Fix CVE-2018-0158: Improper input validation in Cisco IOS and IOS XE
- How to Fix CVE-2018-0171: Improper Input Validation in Cisco IOS and IOS XE
- How to Fix CVE-2018-0151: Buffer overflow in Cisco IOS and IOS XE
People also ask
Is CVE-2018-0173 remote code execution?
No. It is a denial-of-service flaw. A crafted DHCPv4 packet handled by the relay agent causes the affected device to reload. The CVSS 8.6 score reflects availability-only impact (A:H, with confidentiality and integrity both None), no data is read or altered, but the device drops offline until it finishes rebooting.
Which Cisco IOS or IOS XE version fixes CVE-2018-0173?
There is no single fixed version that covers every train. The first fixed release depends on your specific IOS or IOS XE software train. Enter your exact running version into the Cisco IOS Software Checker on advisory cisco-sa-20180328-dhcpr2 to get the correct fixed build for your platform.
Am I affected if I do not use DHCP relay?
The vulnerable code is the DHCPv4 relay agent that restores encapsulated option 82 information. A device with no ip helper-address configured is not relaying DHCPOFFER messages and is not exposed to this vector. Confirm your relay configuration before deprioritizing the upgrade.
Can I mitigate without upgrading?
There is no Cisco-documented workaround. You can lower exposure with DHCP snooping, trusted-server restrictions, and edge ACLs that limit which DHCP servers the relay will accept replies from, but only the upgrade removes the flaw.