Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2018-0155 (Cisco Catalyst Bidirectional Forwarding Detection Denial-of-Service)…
Threats, Abuse & Incident Response

Is CVE-2018-0155 (Cisco Catalyst Bidirectional Forwarding Detection Denial-of-Service) being exploited in the wild?

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

Yes. CISA added CVE-2018-0155 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. Any organisation running the affected product should treat remediation as urgent. Check exposure first, then patch or mitigate, then review logs for signs of earlier compromise.

What It Means When CISA Lists CVE-2018-0155 as Actively Exploited

For a vulnerability question like this, the key issue is not the software flaw in isolation but the fact that it has crossed into active exploitation. Once a CVE appears in the KEV catalogue, security teams should treat it as a live attack path, not a theoretical weakness. That changes prioritisation, response urgency, and what evidence you should look for in logs and network telemetry.

When a network-facing fault can trigger denial of service, the practical concern is usually service disruption first, then availability loss, then any follow-on effects if the outage knocks over monitoring, segmentation, or management functions. For Cisco users, the first check is simply whether the affected product is deployed anywhere in the estate, including overlooked edge devices and delegated environments. The CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm the active-exploitation status and remediation expectation for a specific CVE.

Because KEV inclusion means exploitation has been observed or credibly confirmed, the operational question becomes whether exposure still exists and whether the service is already showing instability or abnormal control-plane behaviour. That is why remediation is urgent even if the device has not obviously failed yet. For the underlying record and naming discipline, keep the CVE Program and vendor advisory in view as the canonical references for the vulnerability itself.

How to Confirm Exposure and Reduce the Blast Radius

Start with asset confirmation, not patching theater. Identify every Cisco Catalyst device that could plausibly be in scope, then verify whether it is running the exposed feature set rather than assuming perimeter placement equals safety. In protocol-level denial-of-service cases, the failure may be immediate or intermittent, so you need to know whether management-plane monitoring, interface counters, or CPU spikes have already hinted at abuse.

If remediation cannot happen immediately, isolate and harden the operational path around the device. That means narrowing who can reach management interfaces, limiting unnecessary protocol exposure, and increasing visibility on the traffic patterns that would indicate repeated triggering attempts. For broader triage of exploited vulnerabilities, the Zero-Day and Exploited Vulnerabilities Guide is useful for prioritising KEV-listed issues, emergency mitigation, and post-patch hunting.

Where patching must wait, the right question is not whether you can eliminate all exposure, but whether you can lower the chance that exploitation translates into outage. That usually means rate limiting, access restriction, temporary feature disablement where supported, and tighter monitoring of device health and connectivity. The goal is to keep the device serviceable long enough to move from emergency containment to permanent remediation.

What to Check After Remediation Is Under Way

Once the exposure path is addressed, review logs and adjacent telemetry for signs of prior abuse. In a denial-of-service case, that can include repeated malformed or burst traffic, unexplained control-plane load, resets, session drops, or correlated loss of forwarding stability. A clean patch does not prove the device was never targeted, only that the immediate weakness is less available now.

If the device supports it, retain evidence before and after remediation so you can compare behaviour, especially where the issue may have caused secondary instability rather than a neat crash signature. If you see persistence-like symptoms, such as repeated recurrence after service restoration, widen the review to adjacent dependencies and upstream traffic sources. For teams managing vulnerability response at scale, Vulnerability Management Guide helps frame prioritisation, exception handling, verification, and remediation tracking.

In practice, the main judgment is whether the event stayed at nuisance level or became a broader availability incident. If the device sits on a critical path, even a short outage can cascade into authentication, routing, or remote administration problems elsewhere in the environment. Treat the outcome as an operational exposure review, not just a patch ticket closure.

Risk and Threat Considerations

Actively exploited protocol flaws are attractive because they can be triggered remotely and repeatedly, often with little need for prior access. For a network device, that means the attacker or opportunistic scanner does not need persistence to cause damage, and repeated attempts can keep a platform unstable even after a restart.

Failure mechanism: A crafted request or traffic pattern forces the affected device into resource exhaustion or control-plane instability, which can interrupt forwarding, management access, or adjacent network services.

Impact: The immediate effect is denial of service, but the downstream effect can be wider operational disruption if the device is part of a critical routing or security path.

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 ManagementKEV-listed exploitation makes prioritised vuln response central to this Cisco CVE.
Recommendation — Prioritise this CVE for remediation and verify exposure across the asset estate.
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationThe answer is about urgent patching and verification after an exploited vulnerability is disclosed.
Recommendation — Track, remediate, and verify this Cisco flaw as a high-priority security defect.
NIST CSF 2.0ID.RA-01 — Asset vulnerabilities are identified and documentedExposure confirmation depends on knowing where the affected Cisco product is deployed.
RS.MA-02 — Incidents are contained and mitigatedActive exploitation requires immediate containment if patching cannot happen at once.
RC.RP-01 — Recovery is planned, managed, and executedPost-remediation validation and service restoration are part of handling an exploited DoS flaw.
Recommendation — Map affected Cisco assets and document where the vulnerable product is present. Contain exposed devices and reduce attack surface until remediation is complete. Validate recovery, confirm service stability, and document post-remediation evidence.

Practitioner Guidance

What to prioritise: Confirm whether any Cisco Catalyst asset in your estate is actually exposed before debating patch windows. For KEV-listed issues, exposure verification and containment should come before routine change scheduling.

What to verify: Check logs, interface counters, and device health telemetry for repeated failures or bursts that line up with attempted exploitation. If the device recovered but the symptoms repeated, treat that as evidence that the issue may already have been probed in your environment.

Practitioner takeaway: A KEV listing is an operational signal, not just an intelligence note, so the correct response is to prove exposure, reduce blast radius, and then verify whether the device has already shown signs of abuse.

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 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org