How to Fix CVE-2017-12234: Cisco IOS CIP Packet Denial of Service

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

What is CVE-2017-12234?

CVE-2017-12234 is a denial-of-service vulnerability in the Common Industrial Protocol (CIP) feature of Cisco IOS. It affects Cisco IOS releases 12.4 through 15.6. The flaw is the improper parsing of crafted CIP packets: when the device receives a malformed CIP packet, the parsing logic mishandles it and the device reloads. Cisco tracks the issue under Bug ID CSCvc43709 and published advisory cisco-sa-20170927-cip on 27 September 2017.

The classification is CWE-20, improper input validation. The important detail for prioritisation is the impact shape. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H: availability impact is High, while confidentiality and integrity impact are both None. That means this is a pure denial of service. There is no remote code execution, no privilege escalation, and no data disclosure here. An attacker who reaches the device over the network and sends crafted CIP packets can force it to reload, and by repeating the packets can hold it in a reload loop, but they cannot run code on it or read data from it through this specific bug.

"Unauthenticated, remote" is what makes the score 7.5. No credentials and no user interaction are needed. If the affected device sits in an industrial or operational-technology network where CIP (EtherNet/IP) traffic is expected, the attack surface is exactly the traffic the device is meant to process, which is why CISA added this to its Known Exploited Vulnerabilities catalog.

Am I affected?

Two conditions both have to be true: the device runs an affected IOS release, and the CIP feature is enabled. Check both from the device CLI in enable mode.

First, confirm the running IOS release:

enable
show version | include Version
! Note the IOS release string, e.g. "Version 15.5(3)M".
! Releases in the 12.4 through 15.6 range are in scope.

Then check whether CIP is actually configured. If CIP is not enabled, this particular DoS vector is not exposed on the device:

! Is the CIP process running and on which interfaces?
show cip status
show cip session

! Or grep the config for CIP configuration
show running-config | include cip

If show cip status returns an active CIP state and your release is between 12.4 and 15.6, the device is vulnerable and should be upgraded. If CIP appears nowhere in the configuration, the specific attack path in CVE-2017-12234 is closed, though running an out-of-support release is still its own risk.

How to fix CVE-2017-12234

The fix is an IOS software upgrade. Cisco did not publish a single "fixed in" version for this CVE because the correction shipped across many IOS trains at different release points. The authoritative way to find the right target image for your device is the Cisco Software Checker, referenced from advisory cisco-sa-20170927-cip under Bug ID CSCvc43709.

Step 1: find the first fixed release for your platform

Open the Cisco Software Checker (linked from the advisory in References below) and enter your platform and current IOS release. It returns the first fixed release on your train. Do not guess a version: the same 15.x number can be fixed on one train and vulnerable on another, so let the checker resolve it against your exact image.

Step 2: stage and boot the fixed IOS image

Download the fixed image from your Cisco account, verify its checksum, copy it to flash, set it as the boot image, and reload during a maintenance window. A device reload drops traffic, so schedule this; the vulnerability itself is also a reload, but a planned upgrade reload is in your control.

enable
! Back up the current config off-box first
copy running-config tftp://10.0.0.5/pre-upgrade-cve-2017-12234.cfg

! Copy the fixed image to flash (TFTP, FTP, SCP or USB all work)
copy tftp://10.0.0.5/c2900-universalk9-mz.SPA..bin flash:

! Verify the image integrity reported by IOS
verify flash:c2900-universalk9-mz.SPA..bin

! Point the boot variable at the fixed image and save
configure terminal
 boot system flash:c2900-universalk9-mz.SPA..bin
 end
write memory

! Reload to run the fixed image
reload

Replace c2900-universalk9-mz.SPA.<fixed-release>.bin with the exact image filename the Software Checker gave you for your platform and feature set. The image name prefix (here a Cisco 2900 ISR universalk9) differs per hardware family.

If you can't patch immediately

If a maintenance window is days away, reduce exposure with one of these IOS-side controls. Neither removes the flaw; both buy time until the upgrade.

Option A: disable CIP if you do not need it

The cleanest mitigation is to turn CIP off on any interface where it is not required. With the feature disabled, the vulnerable parser never sees attacker packets.

enable
configure terminal
interface GigabitEthernet0/1
 no cip enable
end
write memory

! Confirm CIP is no longer active
show cip status

Option B: ACL the CIP / EtherNet/IP ports

If CIP must stay enabled, limit who can send EtherNet/IP traffic to the device. CIP over EtherNet/IP uses TCP/UDP 2222 and UDP 44818. Permit only your trusted industrial hosts and deny the rest, applied inbound on the interfaces facing untrusted segments.

enable
configure terminal
ip access-list extended PROTECT-CIP
 permit tcp host 10.20.0.10 any eq 2222
 permit udp host 10.20.0.10 any eq 2222
 permit udp host 10.20.0.10 any eq 44818
 deny   tcp any any eq 2222
 deny   udp any any eq 2222
 deny   udp any any eq 44818
 permit ip any any
interface GigabitEthernet0/0
 ip access-group PROTECT-CIP in
end
write memory

Adjust the trusted host or subnet to match your PLC and SCADA endpoints. This blocks crafted CIP packets sourced from anywhere outside the allowed industrial hosts.

How to verify the fix worked

After the upgrade reload, confirm three things on the device: the release is the fixed one, the device came back up cleanly, and CIP is in a normal state.

enable
! 1. Confirm the running release matches the fixed image
show version | include Version

! 2. Confirm the boot image and last reload reason
show version | include image|reload|uptime

! 3. Confirm CIP is healthy (if you kept it enabled)
show cip status
show cip session

Expected: the reported release matches the first fixed release the Cisco Software Checker returned for your platform, the last reload reason reflects your planned reload (not a crash), and CIP, if enabled, reports an active, healthy state. If you instead disabled CIP as a mitigation, show cip status should report that CIP is not running.

Frequently asked questions

Am I affected if I do not use industrial protocols?

Only devices running an affected Cisco IOS release (12.4 through 15.6) with the Common Industrial Protocol (CIP) feature enabled are vulnerable. CIP is configured with the cip interface command and is typically used in industrial and manufacturing networks. Run show cip status or show running-config | include cip on the device. If CIP is not configured, this specific attack vector is not exposed, though Cisco still recommends upgrading to a fixed release.

What exactly happens when CVE-2017-12234 is exploited?

An unauthenticated remote attacker sends crafted CIP packets to the device. Because the CIP implementation parses them improperly (CWE-20), the device reloads, dropping all traffic it was switching or routing. The impact is denial of service only (CVSS A:H, C:N, I:N): there is no remote code execution or data disclosure, but a repeated attack can keep the device in a reload loop.

Where do I find the fixed Cisco IOS release?

Cisco does not publish a single fixed version for this CVE because the fix shipped across many IOS trains. Use the Cisco Software Checker linked in advisory cisco-sa-20170927-cip (Bug ID CSCvc43709) with your exact platform and current release to get the first fixed release for your train, then upgrade to it.

Can I mitigate without upgrading immediately?

If CIP is not required, disable it on affected interfaces with no cip enable. If CIP must stay enabled, restrict who can reach EtherNet/IP ports (TCP/UDP 2222 and UDP 44818) with an ACL so only trusted industrial hosts can send CIP traffic to the device. These reduce exposure but do not remove the flaw; upgrade as soon as a maintenance window allows.

References

• Official vendor advisory: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170927-cip
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2017-12234
• CISA KEV catalog entry: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• http://www.securityfocus.com/bid/101038
• http://www.securitytracker.com/id/1039459
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2017-12234

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

Operational notes for fleet remediation

Because CVE-2017-12234 is exploitable pre-authentication from the network, the order of operations matters when you have more than a handful of devices. Inventory first: run show cip status across the fleet and separate devices that actually have CIP enabled from those that do not. Only the CIP-enabled, in-range devices need the emergency upgrade window; the rest can follow your normal patch cadence.

For the in-scope devices, the CISA KEV listing sets the clock. A KEV entry means working attack code is in active use, so the remediation window is days, not a quarter. Where you genuinely cannot schedule a reload in that window, apply the EtherNet/IP port ACL from Option B above as the interim control and record it, so the interim mitigation is not mistaken for the fix when the asset is audited later.

Verify per device, not per batch. A reload that times out, a boot variable that still points at the old image, or a config that was never written to memory will all leave a device on the vulnerable release while your change ticket says "done". Confirm show version on each device shows the fixed release before the ticket closes.

Related fixes

Other flaws in this area worth reviewing while you patch this one:

• How to Fix CVE-2017-12232: Cwe-399 in Cisco IOS
• How to Fix CVE-2017-6742: Improper Restriction of Operations within the Bounds of a Memory Buffer
• How to Fix CVE-2017-6743: Buffer overflow in IOS
• How to Fix CVE-2017-12319: Improper input validation in Cisco IOS XE
• How to Fix CVE-2017-6736: Buffer overflow in IOS