Yes. CISA added CVE-2018-0156 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 Smart Install feature of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to trigger a reload of an affected device, resulting in a denial-of-service (DoS) condition.
What “exploited in the wild” means for this Cisco IOS flaw
For a vulnerability question like this, the practical answer is not just whether the bug is real, but whether there is evidence that attackers are already using it against live systems. CISA’s KEV inclusion is the strongest operational signal that exploitation is not theoretical. For network appliances, that usually means exposure can persist until the device is inventoried, patched, or otherwise isolated.
That matters here because Smart Install is an edge-facing feature on Cisco IOS and IOS XE devices, and edge devices are often reachable before defenders notice they are vulnerable. A reload-triggering flaw can be enough for an attacker to cause immediate service loss even without full compromise, which is why exposed management and control-plane services deserve fast attention.
How to judge exposure and confirm whether the device is at risk
The first step is to determine whether any Cisco IOS or IOS XE devices in your environment expose Smart Install and whether they are still within your supported, patched estate. For this kind of issue, asset inventory is not enough by itself, because the real question is whether the vulnerable feature is enabled or reachable on an internet-facing or broadly reachable interface. NHIMG’s Edge Device Security Guide is useful here because it focuses on exposed appliance management, logging minimums and hardening patterns that make this type of weakness easier to spot.
Confirming exposure also means checking whether the device sits in a path where a reboot would create a material outage. A denial-of-service flaw on a core router, firewall, branch appliance or load balancer is often a business continuity issue, not just a technical bug. If the device supports configuration export and state review, validate whether Smart Install is enabled, whether management interfaces are exposed, and whether compensating controls already reduce reachable attack surface.
What to do when you cannot patch immediately
If patching cannot happen right away, the goal is to reduce reachability and blast radius rather than to assume the issue is harmless because the device has not yet failed. CISA’s Known Exploited Vulnerabilities Catalog is the authoritative place to verify whether the CVE remains listed and whether your remediation deadline is still current. In practice, that should drive temporary containment, such as restricting management-plane exposure, segmenting administration paths, and monitoring for reboot or control-plane instability.
For network-facing infrastructure, the safest temporary response is usually to disable the vulnerable feature if business operations allow it, then limit who can reach the device until a permanent fix is in place. NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is relevant because it frames the right sequence for exploited flaws: triage, emergency mitigation, then verification that the system remained uncompromised while exposure existed.
What to check after patching or mitigation
Once the vulnerability is addressed, verify that the device did not experience unplanned reloads, configuration drift, or adjacent tampering during the exposure window. For a DoS-class flaw, the main question is not only whether the device still functions, but whether any outage masked a separate administrative change or follow-on access. Review logs, management access records and device telemetry for signs of repeated probing, failed attempts or unexpected restarts.
Because the direct effect here is service disruption rather than credential theft, credential rotation is not always the primary response. However, if your response process reveals that the device was also accessible through weak administrative paths, broaden the review to related accounts, shared management credentials and device credentials that could have been exposed during the same period.
Risk and Threat Considerations
Active exploitation changes the priority of this flaw from ordinary maintenance to urgent exposure management. An attacker does not need user interaction or prior foothold to cause impact if the vulnerable feature is reachable, which makes edge devices especially attractive targets for opportunistic scanning and disruption.
Failure mechanism: A remote unauthenticated request can trigger a reload on the affected Cisco device, causing an immediate loss of availability and interrupting routing, access or other dependent services.
Impact: Even when the flaw is “only” denial of service, the operational effect can be broad, including branch outage, network segmentation failure, monitoring blind spots and recovery work that consumes incident response capacity.
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 governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Exploited edge devices need hardened, validated configuration and feature exposure control. |
| CIS-12 — Network Infrastructure Management | Cisco IOS/IOS XE devices are network infrastructure whose reachability and management exposure drive risk. | |
| Recommendation — Disable the vulnerable feature and verify secure baseline configuration on exposed network devices. Restrict management access and monitor infrastructure devices for unsafe exposure. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | A KEV-listed exploited flaw requires rapid identification, remediation and verification. |
| CM-7 — Least Functionality | Disabling Smart Install follows the least-functionality principle for exposed services. | |
| SC-7 — Boundary Protection | Containment depends on limiting who can reach the vulnerable control plane. | |
| Recommendation — Prioritise and remediate the vulnerable Cisco software using emergency flaw-response procedures. Remove or disable unnecessary services and features on network devices. Constrain access paths to the affected device and segment management traffic. | ||
Practitioner Guidance
What to prioritise: Treat KEV-listed infrastructure flaws on exposed network devices as availability incidents with a patching deadline, not as low-noise advisory items. Focus first on externally reachable devices and on any appliance that would create a disproportionate outage if it reloaded unexpectedly.
What to verify: Confirm that the vulnerable feature is disabled or unreachable, that the device is on a supported software branch, and that your monitoring can detect unexpected reloads or control-plane instability before users report a failure.
Practitioner takeaway: For exploited edge-device CVEs, the key decision is whether you can reduce reachability fast enough to survive the remediation window, because once active exploitation is confirmed, “monitor and wait” is usually the wrong answer.
Related resources from NHI Mgmt Group
- CVE-2018-0156 (Cisco IOS Software and Cisco IOS XE Software Smart Install Denial-of-Service)
- Is CVE-2018-0154 (Cisco IOS Software Integrated Services Module for VPN Denial-of-Service) being exploited in the wild?
- Is CVE-2017-12319 (Cisco IOS XE Software Ethernet Virtual Private Network Border Gateway Protocol Denial-of-Service) being exploited in the wild?
- Is CVE-2017-12231 (Cisco IOS Software Network Address Translation Denial-of-Service) being exploited in the wild?