Yes. CISA added CVE-2018-0161 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 Simple Network Management Protocol (SNMP) subsystem of Cisco IOS Software running on certain models of Cisco Catalyst Switches could allow an authenticated, remote attacker to cause a denial-of-service (DoS) condition.
Why this counts as active exploitation, not just a reported flaw
CISA’s inclusion in the Known Exploited Vulnerabilities catalogue is the key signal here: it means the issue is not just theoretical, but is considered to have reliable evidence of active exploitation. For practitioners, that changes the response from normal patch planning to an exploitation-driven prioritisation model, especially for exposed network infrastructure and management planes.
The most important practical distinction is that “being exploited in the wild” does not tell you the attacker’s exact method or whether every affected device is currently at risk in the same way. It does mean the vulnerability has crossed the threshold where defenders should assume real-world targeting, not just lab proof or vendor caution.
That is why confirmed KEV status belongs in the same decision path as zero-day and actively exploited vulnerability response, even when the product is legacy infrastructure rather than internet-facing software.
What exposure to check on Cisco IOS devices
The direct answer identifies the vulnerable surface clearly enough to guide scoping: Cisco IOS Software on certain Catalyst Switch models, with the flaw sitting in the SNMP subsystem and requiring authentication for exploitation. That means exposure assessment should start with device inventory, management-plane reachability, and whether SNMP is enabled and accessible in ways that should not be trusted.
In practice, teams should treat management protocols on network appliances as high-value attack paths because they sit close to availability, configuration integrity, and incident containment. If an authenticated remote user can trigger denial of service, the business consequence is often not just one crashed device, but a disrupted control point that can affect segmentation, monitoring, and downstream traffic handling.
This is a classic edge device security problem: the asset may be “just a switch,” but the operational blast radius can be much larger than the device itself.
What to do when patching or change windows lag
If remediation cannot happen immediately, the priority is to reduce exploitability without creating a false sense of safety. Restrict management access, narrow SNMP exposure to only required administrative sources, and verify that authentication paths, administrative networks, and monitoring tools are not granting broader reach than intended. If the device cannot be patched quickly, document the exception as temporary and time-bounded rather than open-ended.
Because this is an active-exploitation case, delay is itself a risk decision. The question is not only whether the device is vulnerable, but whether the current exposure is acceptable while the organisation waits for maintenance, procurement, or a broader network change window.
For teams managing multiple device families, the vulnerability management guide is useful here because KEV status should move this issue ahead of lower-confidence findings in the queue.
Risk and Threat Considerations
This vulnerability matters because an attacker who can authenticate to the affected SNMP subsystem may be able to disrupt availability on a core network device. On infrastructure that carries production traffic, that can turn a single device flaw into service interruption, incident noise, or loss of visibility during an outage.
Failure mechanism: The attacker abuses the reachable SNMP path on the switch to trigger resource exhaustion or another condition that forces denial of service, often at a point where the device is trusted to stay stable.
Impact: The result can be loss of service on the affected switch, degraded network operations, and increased operational burden while teams restore control and verify that no broader instability followed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Cisco IOS switch exposure and KEV response depend on managing network device hardening and reachability. |
| Recommendation — Limit management-plane exposure and keep network infrastructure configuration tightly controlled. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Confirmed exploitation makes timely vulnerability handling and exception tracking material to this issue. |
| AC-17 — Remote Access | The flaw requires authenticated remote access, so remote-admin path control is central to exposure. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Monitoring access to the management plane helps validate exposure and detect abuse attempts. | |
| Recommendation — Prioritise remediation of exploited flaws and track exceptions until fixed. Restrict remote access paths to only approved administrative sources. Review logs for unusual management-plane activity and authentication events. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Active exploitation makes vulnerability handling and prioritisation directly relevant to affected IOS devices. |
| Recommendation — Track and remediate exploited technical vulnerabilities on affected devices without delay. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed network appliance issues as operationally urgent when the device is internet-reachable, remotely administered, or centrally important to routing, switching, or monitoring. Exposure plus active exploitation is the decision trigger, not exploit detail.
What to verify: Confirm whether the exact models and IOS releases in your environment are present, whether SNMP is enabled, and whether administrative access is limited to approved management paths. If you cannot prove the device is out of scope, assume it needs action.
Practitioner takeaway: For infrastructure vulnerabilities, the meaningful question is often not “is there a patch?” but “how much of the network depends on this device staying up until we apply it?” That framing determines whether you can safely defer remediation or need emergency change handling.
Related resources from NHI Mgmt Group
- CVE-2018-0161 (Cisco IOS Software Resource Management Errors)
- Is CVE-2018-0154 (Cisco IOS Software Integrated Services Module for VPN Denial-of-Service) being exploited in the wild?
- Is CVE-2018-0173 (Cisco IOS and IOS XE Software Improper Input Validation) being exploited in the wild?
- Is CVE-2026-20131 (Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management Deserialization of Untrusted Data) being exploited in the wild?