Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2017-12235 (Cisco IOS Software for Cisco Industrial…
Threats, Abuse & Incident Response

Is CVE-2017-12235 (Cisco IOS Software for Cisco Industrial Ethernet Switches PROFINET Denial-of-Service) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 18, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2017-12235 to its Known Exploited Vulnerabilities catalogue on 3 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A vulnerability in the implementation of the PROFINET Discovery and Configuration Protocol (PN-DCP) for Cisco IOS could allow an unauthenticated, remote attacker to cause an affected device to reload, resulting in a denial of service.

What this CVE means operationally for Cisco IOS Industrial Ethernet switches

The practical question is not whether the flaw exists, it is whether your Industrial Ethernet switch estate is exposed and reachable by an unauthenticated remote actor. Because the affected protocol sits in industrial networking gear, confirmation of exposure should focus on where Cisco IOS Industrial Ethernet Switches are deployed, whether PROFINET traffic is present, and whether the device is internet reachable or otherwise reachable from less trusted networks.

For asset teams, the first pass is scope, not theory. Map the relevant switch models, firmware branches, management paths and network segments, then compare them with the Cisco advisory and the CISA KEV entry. For industrial environments, OT security guidance is useful here because it frames the protocol and segmentation context that determines whether a denial-of-service event can interrupt process connectivity.

Why active exploitation changes the response priority

CISA KEV inclusion is the key signal that moves this issue out of a routine patch queue and into exploitation-aware handling. An exploited denial-of-service flaw is operationally different from a latent bug because the main risk is immediate service interruption, not just theoretical exposure. In industrial networks, loss of switch availability can affect production visibility, control traffic, and dependent systems even when the vulnerable component is not the process controller itself.

The right comparison is not “patched versus unpatched” in the abstract, but “reachable and exposed versus isolated and controlled.” When a vulnerability is already in the wild, delaying remediation only makes the attack window longer. The CISA Known Exploited Vulnerabilities Catalog and the CISA Industrial Control Systems resources are the most relevant external references for prioritising response in industrial settings.

How to reduce exposure when patching is delayed

If remediation cannot happen immediately, the safest interim step is to reduce reachability. That usually means tightening management-plane exposure, restricting who can send traffic to the affected devices, and reviewing segmentation around industrial zones and conduits. For protocol-driven denial of service, the goal is to narrow the set of systems that can reach the vulnerable service, not to rely on detection after the fact.

Verification matters more than aspiration. Confirm that the device is covered by the vendor advisory, that your asset inventory is current, and that no exception process has left the switch exposed longer than intended. The Vulnerability Management Guide is a strong companion for this stage because it emphasises asset scope, KEV-driven prioritisation, exceptions, and verification rather than generic patch cadence.

Risk and Threat Considerations

An exploited PROFINET denial-of-service issue on industrial switching equipment creates a direct availability risk, and in an OT environment that can become a safety, production, or recovery problem very quickly. The threat is attractive because unauthenticated remote triggering lowers attacker effort while the impact can be immediate and visible.

Failure mechanism: A malformed or abusive PN-DCP interaction can force the affected switch to reload, interrupting forwarding and disrupting the communications path that downstream systems depend on.

Impact: The likely result is service interruption across the affected segment, with knock-on effects that may include control instability, loss of telemetry, process delay, or recovery work that is harder than the original fix.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementThe question hinges on known exploited vulnerability prioritisation and exposure reduction.
Recommendation — Prioritise KEV-listed devices for rapid remediation and exposure reduction.
NIST SP 800-53 Rev 5RA-5 — Vulnerability Monitoring and ScanningThis CVE requires exposure confirmation and vulnerability tracking across the affected asset set.
SI-2 — Flaw RemediationActive exploitation makes timely remediation the central control response.
Recommendation — Scan and track affected switches until exposure is verified closed. Remediate the vulnerable Cisco IOS condition as soon as operationally possible.
NIST CSF 2.0GV.RM-01 — Risk Management StrategyKEV status changes remediation priority and risk treatment decisions.
PR.PS-04 — Platform SecurityIndustrial switch hardening and exposure reduction are core to limiting exploitability.
Recommendation — Use risk strategy to escalate KEV-listed vulnerabilities ahead of routine backlog work. Restrict management and protocol exposure on affected industrial switches.

Practitioner Guidance

What to prioritise: Treat KEV-listed industrial network flaws as exposure events, not just patch events. Prioritise devices that are externally reachable, sit on flat or lightly segmented networks, or support business-critical production links.

What to verify: Confirm the exact switch models, the operational role of the affected interface, and whether any compensating control truly limits attack reach. If the device cannot be patched immediately, verify that its exposure is reduced in practice, not only documented in a ticket.

Decision rule: If the switch is reachable from any untrusted or broad internal segment, accelerate containment and maintenance windows before waiting for normal patch cycles. If it is tightly isolated and monitored, you still need timely remediation, but the immediate blast radius is smaller.

Practitioner takeaway: For KEV-listed industrial flaws, the correct question is not “is there a fix,” but “how much operational exposure remains until the fix is actually in place?”

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org