Is CVE-2016-6366 (Cisco Adaptive Security Appliance (ASA) SNMP Buffer Overflow) being exploited in the wild?

Yes. CISA added CVE-2016-6366 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 buffer overflow vulnerability in the Simple Network Management Protocol (SNMP) code of Cisco ASA software could allow an attacker to cause a reload of the affected system or to remotely execute code.

What this means for Cisco ASA exposure

CVE-2016-6366 is not just a historical bug to catalogue. For any Cisco ASA instance that is still reachable and untrusted, the key question is whether it can still be triggered through SNMP and whether the device is still within the exposure path described by Cisco and the CISA Known Exploited Vulnerabilities Catalog. For edge devices, the difference between “present” and “exploitable” is often management reachability, exposure to the internet, and whether the appliance is still maintained as a living control plane.

That is why the practical first step is inventory, not assumption. Confirm where ASA devices exist, whether SNMP is enabled, whether the service is reachable from untrusted networks, and whether the device is still supported. If the appliance is long past its intended lifecycle, the correct response may be retirement or isolation rather than treating patching as the only remediation.

For practitioners building a broader edge-device view, NHIMG’s Edge Device Security Guide is the right lens for management exposure, appliance hardening, logging minimums, and end-of-life planning. Cisco ASA sits squarely in that category: an internet-facing security appliance can become a high-value target even when the exploit itself is “old.”

Why active exploitation changes the priority

Once a vulnerability is in CISA’s KEV catalog, the remediation discussion changes from routine vulnerability management to exploit-driven risk reduction. The issue is no longer whether the flaw exists in the abstract, but whether an attacker can reliably use it against a live device before your change window opens. That is especially important for network appliances because they often sit at trust boundaries and may not have the same defensive visibility as servers and endpoints.

The most useful operational signal is exposure plus consequence. If the ASA handles remote access, segmentation, or perimeter filtering, a crash or code execution path can have outsized impact: service interruption, loss of boundary control, and potential use of the device as a foothold for further access. Even when the direct result is “only” a reload, the business effect can be immediate if the box is fronting critical connectivity.

For a broader prioritisation model, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is useful because it frames KEV-backed response, emergency mitigation, and post-patch hunting as a single workflow. That is the right mindset for exploited network-device flaws: treat confirmed exploitation as a forcing function for urgent action, not as a standard backlog item.

What to do when patching cannot happen immediately

If you cannot remediate at once, reduce exploitability rather than waiting for a perfect maintenance window. The most important mitigations are to remove unnecessary SNMP exposure, restrict management access to trusted admin networks, and ensure any remaining management plane traffic is tightly filtered. On edge appliances, shrinking the attack surface is often more effective than trying to “monitor harder” around an exposed service.

Then verify whether the appliance was already touched. A KEV-listed network device should be checked for unexpected reloads, anomalous configuration changes, unfamiliar admin sessions, and any signs that other credentials on the box may have been exposed during compromise. If the ASA participates in authentication, routing, or remote-access functions, review adjacent systems too, because attackers often pivot through the appliance rather than stopping at the initial crash or code-execution event.

Where teams need a vulnerability-management lens for this decision, NHIMG’s Vulnerability Management Guide helps structure prioritisation, exception handling, verification, and SLA thinking. For a KEV item, the exception should be time-bound, documented, and paired with compensating controls that actually reduce exposure, not just with an assurance that patching is “scheduled.”

Risk and Threat Considerations

Because this flaw is in an edge security appliance and is listed in KEV, the risk is not limited to one device crashing. The broader concern is that a remotely triggerable buffer overflow on a trust-boundary system can become a reliable path to denial of service or code execution before defenders notice normal scanning activity.

Failure mechanism: Untrusted input reaches SNMP processing in Cisco ASA software, overflows memory, and can force a reload or enable remote code execution on the appliance.

Impact: Attackers can disrupt perimeter services, weaken network segmentation, and potentially use the device as an entry point for follow-on access, making any exposed ASA a high-priority target while the condition remains unmitigated.

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.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed Cisco ASA flaws require continuous identification and prioritization of exploitable vulnerabilities.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities based on exploitability and exposure.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Exploited appliance vulnerabilities require timely remediation and validation of corrective action.
	RA-5 — Vulnerability Monitoring and Scanning	Confirming ASA exposure depends on finding where the vulnerable appliance and service remain reachable.
	SC-7 — Boundary Protection	The flaw affects an edge security appliance that enforces network boundaries and management exposure.
Recommendation — Remediate the ASA flaw promptly and verify the fix in the affected environment. Continuously scan and inventory ASA exposure so the vulnerable service is not overlooked. Restrict management-plane access to trusted networks and block unnecessary SNMP exposure.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and recorded	Answering whether the CVE is exploitable in the wild depends on knowing where the ASA exists and is exposed.
Recommendation — Record exposed ASA devices and their vulnerable services in the risk register.

Practitioner Guidance

What to verify: Confirm whether SNMP is enabled, whether the ASA is reachable from untrusted networks, and whether the device is still supported and monitored. If you cannot answer those three questions quickly, you do not yet have a reliable exposure assessment.

Decision rule: If the device is internet-facing or supports critical remote access, treat it as an urgent remediation case and assess compensating controls only after you have isolated or restricted the exposure path. If it is already isolated and SNMP is disabled, validate that state with configuration evidence, not assumption.

Practitioner takeaway: For KEV-listed edge-device flaws, the right question is not “Do we have the CVE?” but “Can an attacker still reach the vulnerable path, and what happens if they do?”