Is CVE-2016-6367 (Cisco Adaptive Security Appliance (ASA) CLI Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2016-6367 to its Known Exploited Vulnerabilities catalogue on 24 May 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 command-line interface (CLI) parser of Cisco ASA software could allow an authenticated, local attacker to create a denial-of-service (DoS) condition or potentially execute code.

What this CVE means for Cisco ASA exposure

CVE-2016-6367 matters because the question is not just whether the flaw exists, but whether it is already being used. CISA’s KEV inclusion means defenders should treat it as an active exploitation issue, not a theoretical parser bug. For internet-facing appliances, that changes the response from routine patch planning to immediate exposure confirmation and containment.

That is especially true for edge devices, where management-plane access, remote administration paths, and delayed maintenance often create a wider blast radius than teams expect. The right first question is whether any ASA instance is reachable, managed, or still in service, because edge device security failures often begin with exactly that kind of overlooked exposure.

How to confirm exposure and close the gap

Start by inventorying every Cisco ASA instance, including standby pairs, lab systems, and remotely administered devices that may not appear in the main asset register. Then confirm whether the vulnerable CLI management path is present in your deployment and whether the device is exposed to untrusted networks, VPN users, or third-party operators. If you cannot answer those questions quickly, you do not yet have a reliable risk picture.

When patching or replacement is delayed, reduce exposure by shrinking administrative reach, tightening source restrictions, and disabling any unnecessary management access paths. For older security appliances, operational drift and incomplete logging are common, so validate both configuration and visibility, not just version state. CISA’s KEV catalogue and the vendor advisory should be the authoritative references for remediation urgency and product-specific action.

Because this issue sits in the same operational class as other actively exploited edge-device flaws, use a dedicated triage path rather than a normal backlog. A good analogue is the pattern described in the Zero-Day and Exploited Vulnerabilities Guide, where time-to-mitigate matters more than waiting for broad maintenance windows.

What to look for after mitigation

If a device may have been exposed before mitigation, check for signs of prior compromise before assuming the risk is gone. For a CLI parser issue, that means reviewing administrator activity, unexpected configuration changes, new accounts, altered access policies, and any unusual outbound or management-plane traffic around the suspected exploitation window. A parser flaw can be used for more than disruption, so absence of a crash is not evidence of absence.

Where the appliance handles privileged credentials, certificates, or secrets that could have been touched during compromise, plan for rotation as part of recovery. That is especially important when the device supports remote access or sits on a trust boundary, because stolen administrative access can outlive the original bug. The Vulnerability Management Guide is a useful reference for prioritisation, verification, and exception handling once the immediate fix is underway.

Risk and Threat Considerations

Exploited edge appliances are attractive because they sit close to authentication paths, management access, and internal connectivity. Even when the original weakness is “only” remote code execution or denial of service, the downstream risk is often broader: attackers may gain a durable foothold, intercept administrative traffic, or use the device as a stepping stone into more sensitive networks.

Failure mechanism: An authenticated local attacker abuses the CLI parser to trigger code execution or a denial-of-service condition, then leverages the appliance’s privileged position to extend access or disrupt availability.

Impact: You may face service interruption, management-plane compromise, and follow-on exposure of adjacent systems if the appliance was trusted as a control point.

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-7 — Continuous Vulnerability Management	Active exploitation requires rapid identification and remediation of exposed appliances.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	ASA exposure depends on hardening management access and reducing attack surface.
Recommendation — Prioritise KEV-listed assets for immediate remediation and verify exposure continuously. Harden management interfaces and remove unnecessary administrative exposure.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV-listed CVEs require targeted discovery and validation of vulnerable assets.
	SI-2 — Flaw Remediation	The issue is an exploited flaw that needs prompt remediation and exception tracking.
	AC-6 — Least Privilege	Compromise impact depends on how much privilege the appliance and admins retain.
Recommendation — Scan for the vulnerable appliance condition and track remediation until closed. Apply the fix or mitigation promptly and manage any delay as an exception. Restrict administrative access paths to the minimum required privilege.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as a response queue, not a normal patch queue. Confirm whether the device is in production, externally reachable, and still required, then decide whether patching, isolation, or retirement is the fastest safe option.

What to verify: Validate the actual attack surface, not just the installed software record. A device that is technically patched but still remotely manageable from broad networks, or still used as a privileged access path, remains operationally risky.

Practitioner takeaway: For exploited infrastructure flaws, the real decision is whether you can still trust the appliance’s management plane and adjacency to remain uncompromised, not whether the CVE looks “local” in the abstract.