How to Fix CVE-2017-12235: Cisco IOS PROFINET (PN-DCP) 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-12235?

CVE-2017-12235 is a denial-of-service vulnerability in how Cisco IOS implements the PROFINET Discovery and Configuration Protocol (PN-DCP). It affects Cisco IOS releases 12.2 through 15.6 on devices that are configured to process PROFINET messages. An unauthenticated, remote attacker can make an affected device reload. that is, crash and reboot, which drops all traffic passing through it until it comes back up. This is an availability problem only: there is no code execution, no privilege escalation, and no data disclosure. That is exactly why the CVSS 3.1 vector reads C:N/I:N/A:H (confidentiality none, integrity none, availability high) for a base score of 7.5.

The root cause is improper parsing of ingress PN-DCP Identify Request packets (CWE-20, improper input validation). According to Cisco's own description, the attack pattern is specific: the attacker sends a single crafted PN-DCP Identify Request packet, then continues sending normal PN-DCP Identify Request packets. That sequence drives the device into a reload. Because PN-DCP is a layer-2 protocol, the attacker generally needs to be on the same Ethernet segment (the industrial VLAN) as the target rather than routing in from the internet.

The exposure is wider than many operators expect. Starting with Cisco IOS Software Release 12.2(52)SE, PROFINET is enabled by default on all base switch module and expansion-unit Ethernet ports of the affected platforms. So if you deployed a Cisco Industrial Ethernet (IE) switch and never touched the PROFINET configuration, it is very likely listening: and exposed. Cisco tracks this issue internally as Bug ID CSCuz47179.

It helps to understand what PN-DCP actually does on the wire. PROFINET is the industrial Ethernet protocol used to connect PLCs, drives, and remote I/O on a factory floor. Discovery and Configuration Protocol (PN-DCP) is the layer-2 sublayer an engineering station uses to find devices and assign them a station name or IP address before cyclic data exchange begins. An Identify Request is a broadcast or unicast PN-DCP frame that asks “who is on this segment?” In a healthy plant the IE switch parses these requests as part of participating in the PROFINET network. The flaw here is not in PROFINET itself but in how this one Cisco IOS parser handles a malformed Identify Request followed by a stream of normal ones, the combination drives the device into a watchdog-triggered reload rather than gracefully discarding the bad frame.

Two properties make this serious despite being “only” a DoS. First, it is unauthenticated and pre-association: PN-DCP runs before any PROFINET handshake, so an attacker does not need credentials, an established session, or even a valid station identity. Second, CISA's SSVC scoring marks the flaw Automatable=yes with Exploitation=active, meaning the trigger packet can be scripted and fired repeatedly. An attacker who can place frames on a participating port can hold the switch in a reload loop indefinitely, which on a plant floor is functionally an outage of everything behind that switch.

Why this one is urgent

CISA added CVE-2017-12235 to the Known Exploited Vulnerabilities catalog on 2022-03-03, listed as the “Cisco IOS Software for Cisco Industrial Ethernet Switches PROFINET Denial-of-Service Vulnerability.” In an operational-technology (OT) environment, a switch reload is not a minor blip. it can stop a production line, an HMI, or a safety-relevant control loop. The Automatable=yes / Exploitation=active scoring from CISA means a single attacker on the plant network can script repeated reloads. Treat a PROFINET-enabled IE switch in scope as an emergency change.

Check whether you are affected

From the device CLI, confirm two things: the IOS version and whether PROFINET is actually running. Both checks are Cisco IOS commands, nothing else applies here.

enable
show version | include Version
! Is the device in the 12.2-15.6 range?

show profinet
! If PROFINET shows as enabled on any port, the attack surface is live.

show running-config | include profinet
! Confirms per-interface and global PROFINET configuration.

If show version reports an IOS train between 12.2 and 15.6 and show profinet shows PROFINET enabled on one or more ports, the device is exposed. If PROFINET is not enabled anywhere, this specific CVE cannot be triggered against that box: but you should still plan the upgrade so a future config change does not silently re-expose it.

One caveat specific to this CVE: because PROFINET defaults to on from 12.2(52)SE forward, the absence of any profinet line in show running-config does not mean PROFINET is disabled. On affected IE platforms the feature can be active even when nothing about it appears in the saved configuration, which is exactly how operators end up exposed without realising it. Trust the live show profinet operational state over what the config text implies, and treat any IE-series switch on an industrial train as in-scope until you have positively confirmed PROFINET is off on every port.

How to fix CVE-2017-12235

The permanent fix is to upgrade to a Cisco IOS release that contains the patch for CSCuz47179. Cisco does not publish a single universal fixed build for this CVE, the corrected release depends on your exact platform and IOS train. Do not guess at a version number. Use the Cisco Software Checker linked from the advisory (cisco-sa-20170927-profinet) to look up the first fixed release for your specific model and current train, then upgrade to that image.

Upgrade the IOS image

This is the standard IOS image-upgrade flow run directly on the device console or over SSH. Back up first, stage the fixed image Cisco gave you in the Software Checker, set it as the boot image, and reload during a maintenance window.

! Vendor advisory: cisco-sa-20170927-profinet  (Bug ID CSCuz47179)
enable
show version | include Version

! 1. Back up the current config off-box
copy running-config startup-config
copy startup-config tftp://10.0.0.10/ie-switch-pre-cve-2017-12235.cfg

! 2. Copy the FIXED image (from Cisco Software Checker) into flash
copy tftp://10.0.0.10/<fixed-ios-image>.bin flash:

! 3. Verify the image integrity before booting it
verify flash:<fixed-ios-image>.bin

! 4. Point the boot system at the fixed image
configure terminal
 no boot system
 boot system flash:<fixed-ios-image>.bin
 end
write memory

! 5. Reload during the maintenance window
reload

After the device comes back, confirm the running version matches the fixed release Cisco listed for your platform:

show version | include Version
! Compare against the first-fixed release from the Cisco Software Checker.

If you can't patch immediately

If you cannot schedule the IOS upgrade right away, you can remove the attack surface or restrict reachability. These are real mitigations Cisco's design allows. but none of them replace the fixed image.

Disable PROFINET where it isn't needed

This is the most effective workaround. If a switch or a given interface does not need to speak PROFINET, turn it off, that eliminates the vulnerable parser path entirely.

configure terminal
! Disable PROFINET globally if nothing on the box uses it
 no profinet

! Or disable it only on interfaces that don't need it
 interface range GigabitEthernet1/1 - 24
  no profinet
 end
write memory

! Confirm it is gone
show profinet

Restrict the layer-2 domain

PN-DCP is a layer-2 protocol, so an attacker has to reach the switch on the same broadcast domain. Tightening who shares the industrial VLAN limits exposure while you stage the upgrade.

! Keep the PROFINET/industrial VLAN isolated from general user and IT traffic.
! Only trusted automation hosts and PLCs should share that broadcast domain.
configure terminal
 interface GigabitEthernet1/1
  switchport mode access
  switchport access vlan 200    ! dedicated, isolated industrial VLAN
 end
write memory

Do not rely on VTY ACLs or management-plane filters for this one: the trigger is a data-plane PN-DCP frame on a participating port, not a management-protocol session, so a line vty access-class will not stop it. Disabling PROFINET or isolating the VLAN are the controls that actually move the needle.

Be realistic about each mitigation's limits. Disabling PROFINET is clean and complete, but only safe where the switch genuinely does not need to participate in the PROFINET network, turning it off on a port that carries live device-name assignment will break discovery for whatever is plumbed behind it. VLAN isolation reduces who can reach the parser but does nothing about a malicious or compromised host that is already inside the industrial VLAN, which on a flat OT network is a common reality. Layer-2 access control lists that drop PN-DCP EtherType 0x8892 frames from untrusted ports can help on platforms that support port ACLs, but verify the ACL does not also break legitimate PROFINET traffic on ports that need it. None of these change the underlying parser bug; they only shrink who can reach it, which is why Cisco's guidance and the KEV due date both point at the fixed image as the real remediation.

Frequently asked questions

Is CVE-2017-12235 remote code execution?

No. It is a denial-of-service flaw. A malformed PN-DCP Identify Request makes the device reload, dropping traffic while it reboots. There is no code execution or data theft. the CVSS vector is C:N/I:N/A:H, pure availability impact. The danger in an OT plant is the outage, not a breach.

Which Cisco devices are affected?

Cisco IOS 12.2 through 15.6 on devices configured to process PROFINET. Because PROFINET is on by default from release 12.2(52)SE, Cisco Industrial Ethernet (IE) switches are the main exposure. Confirm with show version and show profinet.

What is the fixed version?

There is no single universal build. Cisco published per-platform fixed releases under advisory cisco-sa-20170927-profinet (Bug ID CSCuz47179). Use the Cisco Software Checker on the advisory page to get the first fixed image for your exact model and IOS train.

Can I mitigate it without upgrading?

Yes, temporarily. Disable PROFINET with no profinet on interfaces or globally where it is not needed, and keep the industrial VLAN isolated to trusted automation hosts. These remove or shrink the attack surface but are stopgaps, apply the fixed IOS image as the permanent fix.

References

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

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

Operational notes for OT environments

A few points worth keeping in the runbook for this specific CVE. First, the trigger is a data-plane PN-DCP frame, not a management session, so anyone who can place a frame on a participating port can attempt it. That makes physical and VLAN segmentation of the industrial network a genuine compensating control, not just a checkbox. Second, because the impact is a reload rather than a compromise, a successful attack looks like an unexplained device reboot in your logs: check show version uptime and any syslog reload reasons if a PROFINET-enabled IE switch restarts without a known cause.

Third, prioritisation: this CVE is on the CISA KEV list with an availability-only impact, which is unusual. In an IT data centre a brief switch reload might be tolerable; on a plant floor it can halt production or interrupt a control loop, so the business impact is what should drive your maintenance-window timing, not the CVSS number alone. Confirm the fixed image with the Cisco Software Checker for your exact platform before staging it, because aggregator sites sometimes lag or list a fix that only covers part of the affected train.

Fourth, detection. Since a successful attack manifests as a reload rather than a compromise, your earliest signal is repeated unexplained restarts of a PROFINET-enabled IE switch. After any unexpected reboot, capture show version for the last-reload reason and uptime, pull show logging for the events immediately before the restart, and check whether the box was reachable by an unexpected host on the industrial VLAN at that time. A pattern of reloads clustered around a single source MAC on a participating port is a strong indicator of exploitation rather than a hardware fault. Pair that with NetFlow or SPAN capture on the industrial VLAN if you have it, so you can tell a crafted PN-DCP burst apart from ordinary discovery traffic.

Finally, plan the upgrade as one change rather than a perpetual workaround. The mitigations above buy time, but a PROFINET-enabled switch sitting on an industrial train will remain a KEV-listed liability until it runs a fixed image. Stage the Cisco-listed first-fixed release for your platform, validate it on a bench or non-production IE switch where you can, and roll it during a maintenance window with the device backup already taken. Because the fix is platform-specific, do this lookup per model, a mixed fleet of IE 2000, IE 3000, and IE 4000 switches will not all land on the same release.

Related fixes

Additional nearby issues sensible to fix in the same maintenance window:

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