How do you patch or mitigate CVE-2016-6367 (Cisco Adaptive Security Appliance (ASA) CLI Remote Code Execution)?

CISA’s required action for CVE-2016-6367 is to apply updates per vendor instructions. In practice, find every instance of Cisco Adaptive Security Appliance (ASA) in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What should you patch first on Cisco ASA?

Start by inventorying every Cisco Adaptive Security Appliance instance, then confirm which devices are internet-facing, remotely managed, or still required in production. For a flaw with known exploitation, exposure reduction is part of the remediation, not a fallback, so patching should be paired with rapid removal of unnecessary public access and shutdown of any appliance you no longer need.

When the vendor update is available, apply it exactly as directed and validate that the intended management plane and CLI access paths are no longer reachable from untrusted networks.

What if the ASA cannot be patched immediately?

If you cannot install the vendor fix right away, treat the device as a high-risk exposed asset and narrow its reachable surface to the smallest practical set of trusted sources. The safest temporary posture is documented mitigation plus strong network restriction, not a long exception window.

That usually means removing internet exposure, restricting management access to known administrative networks, and, where necessary, taking the product out of service until a supported remediation path is available.

What should you check after remediation?

Once the device is updated or isolated, review logs and adjacent telemetry for indicators of earlier compromise. For an actively exploited remote code execution issue, post-remediation validation should look for suspicious CLI activity, unexpected configuration changes, new accounts or access paths, and any sign that the appliance was used as a pivot point.

Because the vulnerable interface was the control plane itself, assume the impact could extend beyond the initial exploit attempt if the device was exposed for any length of time.

Risk and Threat Considerations

This vulnerability is especially dangerous when the ASA is directly reachable from the internet, because cli remote code execution can turn an edge device into an immediate foothold. If attackers reached the appliance before remediation, they may have been able to alter configuration, create persistence, or use the trusted position of the device to move deeper into the network.

Failure mechanism: The exposure comes from a remotely reachable management or CLI path that allows arbitrary code execution on an internet-facing security appliance, bypassing the normal trust boundary around the edge device.

Impact: A compromised ASA can expose credentials, routes, VPN access, and administrative control, so remediation must include both patching and a compromise review, not just version replacement.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 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	ASA patching and exposure reduction require hardened, verified asset configuration.
	CIS-12 — Network Infrastructure Management	The issue affects an internet-facing network appliance and its management plane.
	CIS-17 — Incident Response Management	Known exploitation requires log review and compromise assessment after remediation.
Recommendation — Harden ASA exposure, remove unnecessary public access, and verify secure configuration after remediation. Restrict management reachability and review network appliance access paths before returning it to service. Investigate for prior exploitation and preserve evidence before closing the case.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The primary action is vendor-directed remediation of a known exploited flaw.
Recommendation — Apply the vendor update or documented mitigation and track remediation completion.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management Plan	The subject is a patch-or-mitigate response to a known exploited vulnerability.
Recommendation — Use a defined remediation process to patch, mitigate, and verify exposed ASA assets.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Compromised edge appliances can expose credentials, tokens, and access material.
	NHI-07 — Long-Lived Secrets	Appliance-admin access often persists through long-lived secrets that widen blast radius.
Recommendation — Review for leaked secrets and rotate any credentials the ASA may have exposed. Rotate any long-lived administrative secrets associated with the appliance after remediation.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The flaw is an externally exploitable entry point on an exposed device.
	T1068 — Exploitation for Privilege Escalation	CLI RCE can directly raise attacker privileges on the appliance.
	T1021 — Remote Services	Administrative access over remote management channels is central to the exposure.
Recommendation — Hunt for exploitation of the exposed ASA and contain any internet-reachable management surface. Treat successful exploitation as a likely privilege-escalation event and assess downstream access. Review remote administration channels and disable unnecessary paths to the ASA.

Practitioner Guidance

What to prioritise: Patch first, but rank externally reachable appliances ahead of anything internal-only. If you have multiple ASA instances, the highest-risk one is the device with the broadest management exposure and the least compensating control around administrative access.

What to verify: Confirm the vendor fix or mitigation was applied successfully, then verify that no residual public access remains to the management surface. If you rely on a temporary mitigation, document the exception expiry and the compensating restriction that actually reduces exposure.

Practitioner takeaway: For an exploited edge-device RCE, the security decision is not “patch or not”, it is “patch, constrain exposure, and check for prior compromise as one response.”