How to Fix CVE-2017-12233: Improper input validation in Cisco IOS

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-12233?

CVE-2017-12233 is a remote denial-of-service vulnerability in the Common Industrial Protocol (CIP) implementation of Cisco IOS, covering releases 12.4 through 15.6. CIP is the application-layer protocol behind EtherNet/IP, the standard used to talk to PLCs and other industrial automation gear. On a Cisco router or switch that has the CIP feature enabled, the parser that reads incoming CIP packets does not validate them properly. That is the CWE-20 classification: improper input validation.

The consequence is a reload. An unauthenticated, remote attacker sends crafted CIP packets at the device, the parser chokes, and the device restarts. While it reboots, every interface goes down and all traffic through it stops. That is the whole impact. This is not remote code execution, it is not privilege escalation, and it does not leak data. The CVSS 3.1 vector says so plainly: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Confidentiality and integrity impact are None. Availability impact is High. The base score is 7.5.

Why does a network DoS rate 7.5? Because the prerequisites are minimal. No credentials. No user interaction. Low attack complexity. Any host that can route a packet to the CIP service on the device can knock it over, and CISA's record marks the flaw as Automatable: yes, meaning the attack can be scripted and fired at scale. The Cisco bug that tracks it is CSCuz95334.

If you run industrial or OT networks where Cisco IOS devices sit between a SCADA layer and the plant floor, a forced reload is not a minor blip. It can drop the link to a PLC mid-process. That is the real-world cost here, not stolen data.

Am I affected?

Two conditions have to both be true. First, the device runs Cisco IOS in the 12.4 to 15.6 range. Second, the CIP feature is actually enabled. CIP is not on by default on a generic router, so plenty of IOS devices in that version range are not exposed. Check both.

Confirm the running version from the device CLI:

! Cisco IOS / IOS XE
enable
show version | include Version

Then check whether CIP is configured. The feature shows up under the CIP configuration and you can confirm it is running:

! Is the CIP feature enabled?
show running-config | include cip
show cip status

If show cip status reports the service running and your IOS train is between 12.4 and 15.6, the device is in scope. If CIP is not configured at all, the attack surface for this specific CVE is not present, though you should still confirm against the advisory because Cisco lists the affected platforms and trains authoritatively there.

How to fix CVE-2017-12233

The fix is a Cisco IOS upgrade to a fixed release. There is no Linux package, no apt or yum command, no Windows Update, and no service to systemctl stop here. Cisco IOS is a monolithic network operating system image. You replace the whole image and reload the device.

Cisco does not publish a single fixed version string that applies to every box, because the fixed train differs by platform and by the release you are currently on. The CVE record itself carries no fixed-version field. The authoritative mapping lives in the advisory, cisco-sa-20170927-cip. Use the Cisco Software Checker or the advisory's fixed-software table with your exact platform and current release to get the right target image. Do not guess a version.

The IOS upgrade procedure

The general flow on a classic IOS device is: confirm the fixed image from the advisory, download it from Cisco, copy it to the device flash, set it as the boot image, and reload during a maintenance window. Back up your config first.

! On the device, during a maintenance window
enable

! 1. Back up the running config off-box first
copy running-config tftp:
copy running-config startup-config

! 2. Check free space, then copy the fixed image into flash
dir flash:
copy tftp: flash:
!   (you will be prompted for the TFTP server IP and the image filename
!    of the fixed release you pulled from the Cisco advisory)

! 3. Point the device at the new image
configure terminal
 no boot system
 boot system flash:<fixed-image-from-advisory>.bin
 end
write memory

! 4. Reload during the window
reload

After the device comes back, confirm it is running the fixed release:

show version | include Version
! Compare the reported release against the fixed train in cisco-sa-20170927-cip

One note from doing these upgrades on production switches: verify the image's MD5 hash against the value Cisco lists on the download page before you set it as the boot image. A truncated TFTP transfer that you only discover after the reload turns a 10-minute maintenance window into a console-cable recovery session.

If you can't upgrade IOS immediately

If you cannot schedule the upgrade today, you can shrink the attack surface. These mitigations reduce exposure. They do not remove the bug, so still plan the upgrade.

Disable CIP if you do not need it

If the device does not actually need to speak CIP, turn the feature off. No CIP parser, no CIP-triggered reload.

configure terminal
 no cip enable
end
write memory
! Confirm it is gone
show cip status

Restrict CIP / EtherNet/IP traffic with an ACL

If you do need CIP, only let trusted industrial hosts reach it. EtherNet/IP uses TCP and UDP port 44818 for explicit messaging and UDP 2222 for implicit I/O. Permit those only from your known automation subnet and drop the rest at the interface facing the broader network.

configure terminal
ip access-list extended PROTECT-CIP
 ! allow CIP only from the trusted automation subnet
 permit tcp 10.20.0.0 0.0.255.255 host 10.20.1.1 eq 44818
 permit udp 10.20.0.0 0.0.255.255 host 10.20.1.1 eq 44818
 permit udp 10.20.0.0 0.0.255.255 host 10.20.1.1 eq 2222
 ! deny CIP from anywhere else, log it
 deny tcp any any eq 44818 log
 deny udp any any eq 44818 log
 deny udp any any eq 2222 log
 permit ip any any
exit
interface GigabitEthernet0/1
 ip access-group PROTECT-CIP in
end
write memory

Adjust the subnets, host address, and interface to your topology. The point is that an unauthenticated attacker from an untrusted segment can no longer deliver the crafted CIP packet to the parser.

Verify the fix held

After the upgrade, three checks tell you the device is actually fixed and stable. Run them in order.

! 1. Confirm the running release matches the fixed train in the advisory
show version | include Version

! 2. Confirm the device did not crash on its last reload for the wrong reason
show version | include uptime
show logging | include CRASH

! 3. If you kept CIP, confirm it is still serving the legitimate hosts
show cip status
show cip connection

If the reported release is at or above the fixed train listed in cisco-sa-20170927-cip, the parser bug is closed. If you applied the ACL mitigation instead of upgrading, confirm your deny ... log lines are catching probe traffic and your automation hosts still connect. A mitigation that also breaks the PLC link is not a win.

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-12233
• 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-12233

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 and OT environments

A few things are worth knowing before you touch a production device for this one. CIP and EtherNet/IP live in industrial networks, so the Cisco IOS box affected here is often sitting between an IT segment and a plant floor. That changes the math on a reload. A 90-second reboot on a campus access switch is an annoyance; the same reboot on a switch carrying I/O traffic to a PLC can halt a process line. Schedule the upgrade like you would any OT change, with the process owner in the loop, not as a routine after-hours push.

The fixed-version question trips people up because the CVE record has no fixed-version field at all. That is not an oversight to paper over with a guess. Cisco maps the fix per platform and per train in the advisory and in the Cisco Software Checker. Two devices both running an affected 15.x release can have different correct target images. Pull the target from the advisory for the exact platform in front of you, every time.

Confirm whether you are actually exposed

Before scheduling anything, prove CIP is enabled. Many IOS devices in the 12.4 to 15.6 range never turn the feature on, which means this specific CVE cannot be triggered against them. show cip status and show running-config | include cip answer that in seconds. If CIP is off and you have no plan to use it, the cleanest mitigation is to leave it off and prioritise other patches first, while still tracking the IOS upgrade for the next maintenance window.

Why a DoS still earns an emergency window

It is tempting to deprioritise a flaw that only causes a reload. Resist that here. The CVSS 7.5 and the KEV listing both reflect the same reality: the attack needs no credentials, no user interaction, and can be automated. In an OT context, availability is the security property that matters most, and an attacker who can reboot your industrial switch at will has an effective off-switch for the process behind it. That is why CISA gave federal agencies a hard remediation deadline rather than treating it as a routine fix.

What to verify before you close the change

The verification that matters is on the device itself, not on a generic host. Confirm the running release matches the fixed train from the advisory with show version. Confirm the box came up clean and is not in a reload loop with show logging. If you kept CIP enabled, confirm legitimate automation hosts still establish CIP connections with show cip connection. Only when all three line up should you mark the change complete and note the before-and-after release in your change record.

Related fixes

Nearby vulnerabilities you may as well remediate alongside this fix:

• How to Fix CVE-2017-6742: Improper Restriction of Operations within the Bounds of a Memory Buffer
• How to Fix CVE-2017-3881: Improper Input Validation in Cisco IOS and IOS XE
• How to Fix CVE-2017-12231: Cwe-399 in Cisco IOS
• How to Fix CVE-2017-12235: Improper input validation in Cisco IOS
• How to Fix CVE-2017-12237: Cwe-399 in Cisco IOS and IOS XE