Yes. CISA added CVE-2017-6738 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. The Simple Network Management Protocol (SNMP) subsystem of Cisco IOS and IOS XE contains a vulnerability that could allow an authenticated, remote attacker to remotely execute code.
What “being exploited in the wild” means for this CVE
CISA’s KEV listing is the practical signal that matters here: it means the vulnerability has credible evidence of active abuse, not just a theoretical proof of concept. For CVE-2017-6738, that changes the question from “could this be dangerous?” to “is this asset still exposed to a known exploitation path?”
Because the affected surface is SNMP on Cisco IOS and IOS XE, the first operational question is whether any routers, switches, or appliances still expose that subsystem in production. For edge and network devices, exposure often persists because these systems are long-lived, remotely managed, and easy to overlook during routine vulnerability triage; NHIMG’s Edge Device Security Guide is useful background on why those assets need tighter ownership and logging discipline.
How to judge exposure and reduce immediate risk
The right response is to identify every Cisco IOS and IOS XE system that could be reached through the vulnerable SNMP subsystem, then compare that inventory against the vendor advisory and CISA KEV entry. Do not rely on generic asset tags alone; network devices often drift into service without clean ownership, and unmanaged management access is a common reason exploited infrastructure stays exploitable.
If patching or firmware upgrade must wait, the mitigation priority is to shrink the exposed attack surface: restrict management reachability, disable unused SNMP exposure, segment administrative access, and verify that only intended administrative sources can talk to the device. That is not a substitute for remediation, but it can meaningfully reduce the chance of opportunistic exploitation while a maintenance window is being scheduled.
For this kind of issue, a vulnerability process that can separate “known exploited” from merely “known” matters more than a raw CVE count. NHIMG’s Vulnerability Management Guide is relevant because it emphasises KEV-driven prioritisation, exception handling, and verification instead of calendar-driven patching.
What to check for after patching or mitigation
Once exposure is reduced, look for signs that the device was already touched before controls were applied. On network infrastructure, that means reviewing configuration changes, unexpected admin sessions, new accounts or privilege changes, abnormal SNMP-related traffic, and any evidence that command execution was used to alter the device or pivot deeper into the network.
Where the exploited asset is an edge or network device, compromise assessment should focus on persistence and lateral movement rather than just file integrity. Attackers often value these systems because they sit at trust boundaries, have broad visibility, and can be used to intercept traffic, change routing, or stage access to other management planes. That is why a forensic review should be tied to the device’s role in the network, not treated as a generic host investigation.
When organisations need a precedent for how network infrastructure abuse can support persistence and spread, NHIMG’s Salt Typhoon telecom intrusions 2025 is a useful reminder that network device exposure can become a long-tail access problem, not a one-time patch issue.
Risk and Threat Considerations
KEV inclusion means this is no longer a hypothetical Cisco management-plane flaw, it is an actively exploited weakness that can be used against exposed infrastructure. For Internet-facing or weakly segmented network devices, the main risk is not only initial compromise but also the control the attacker may gain over traffic handling, monitoring, and downstream administrative access.
Failure mechanism: An authenticated remote attacker abuses the SNMP subsystem to execute code on Cisco IOS or IOS XE, then uses that foothold to change configuration, persist, or pivot within the network.
Impact: The result can include device takeover, traffic manipulation, loss of trust in management access, and wider compromise of adjacent systems that depend on the network device as a trusted control point.
What “being exploited in the wild” means for this CVE
CISA’s KEV listing is the practical signal that matters here: it means the vulnerability has credible evidence of active abuse, not just a theoretical proof of concept. For CVE-2017-6738, that changes the question from “could this be dangerous?” to “is this asset still exposed to a known exploitation path?”
Because the affected surface is SNMP on Cisco IOS and IOS XE, the first operational question is whether any routers, switches, or appliances still expose that subsystem in production. For edge and network devices, exposure often persists because these systems are long-lived, remotely managed, and easy to overlook during routine vulnerability triage; NHIMG’s Edge Device Security Guide is useful background on why those assets need tighter ownership and logging discipline.
How to judge exposure and reduce immediate risk
The right response is to identify every Cisco IOS and IOS XE system that could be reached through the vulnerable SNMP subsystem, then compare that inventory against the vendor advisory and CISA KEV entry. Do not rely on generic asset tags alone; network devices often drift into service without clean ownership, and unmanaged management access is a common reason exploited infrastructure stays exploitable.
If patching or firmware upgrade must wait, the mitigation priority is to shrink the exposed attack surface: restrict management reachability, disable unused SNMP exposure, segment administrative access, and verify that only intended administrative sources can talk to the device. That is not a substitute for remediation, but it can meaningfully reduce the chance of opportunistic exploitation while a maintenance window is being scheduled.
For this kind of issue, a vulnerability process that can separate “known exploited” from merely “known” matters more than a raw CVE count. NHIMG’s Vulnerability Management Guide is relevant because it emphasises KEV-driven prioritisation, exception handling, and verification instead of calendar-driven patching.
What to check for after patching or mitigation
Once exposure is reduced, look for signs that the device was already touched before controls were applied. On network infrastructure, that means reviewing configuration changes, unexpected admin sessions, new accounts or privilege changes, abnormal SNMP-related traffic, and any evidence that command execution was used to alter the device or pivot deeper into the network.
Where the exploited asset is an edge or network device, compromise assessment should focus on persistence and lateral movement rather than just file integrity. Attackers often value these systems because they sit at trust boundaries, have broad visibility, and can be used to intercept traffic, change routing, or stage access to other management planes. That is why a forensic review should be tied to the device’s role in the network, not treated as a generic host investigation.
When organisations need a precedent for how network infrastructure abuse can support persistence and spread, NHIMG’s Salt Typhoon telecom intrusions 2025 is a useful reminder that network device exposure can become a long-tail access problem, not a one-time patch issue.
Risk and Threat Considerations
KEV inclusion means this is no longer a hypothetical Cisco management-plane flaw, it is an actively exploited weakness that can be used against exposed infrastructure. For Internet-facing or weakly segmented network devices, the main risk is not only initial compromise but also the control the attacker may gain over traffic handling, monitoring, and downstream administrative access.
Failure mechanism: An authenticated remote attacker abuses the SNMP subsystem to execute code on Cisco IOS or IOS XE, then uses that foothold to change configuration, persist, or pivot within the network.
Impact: The result can include device takeover, traffic manipulation, loss of trust in management access, and wider compromise of adjacent systems that depend on the network device as a trusted control point.
Practitioner Guidance
What to prioritise: Confirm whether any Cisco IOS or IOS XE systems are still reachable through the vulnerable SNMP path, then treat those devices as high priority if they are exposed to untrusted networks or broad administrative access. For infrastructure flaws like this, exposure and asset criticality matter more than whether a successful exploit has already been observed in your environment.
What to verify: Validate patch status against the vendor advisory, then verify that management access is limited to approved sources and that logging is sufficient to spot changes in configuration or session behaviour. If you cannot verify who can reach the management plane, you do not yet know whether the vulnerability is meaningfully contained.
Practitioner takeaway: For a KEV-listed network device flaw, the practical decision is to treat exposure as an incident-prevention problem, not just a patch ticket, because confirmed exploitation means the control question is “what can still be reached?” rather than “is there a fix?”
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 | Applies to hardening exposed Cisco network devices and reducing exploitable management surface. |
| CIS-7 — Continuous Vulnerability Management | Applies because KEV-listed exploitation demands exposure discovery, prioritisation, and remediation verification. | |
| Recommendation — Harden device configuration and restrict management exposure on Cisco IOS and IOS XE assets. Prioritise KEV-listed Cisco devices for remediation and verify closure after mitigation. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Applies to remediating a known exploited vulnerability on production network infrastructure. |
| CM-6 — Configuration Settings | Applies to limiting SNMP exposure and enforcing secure management-plane settings. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Applies to reviewing logs for exploitation signs and post-compromise activity on network devices. | |
| Recommendation — Remediate the Cisco flaw promptly and track exception approval until the device is fixed. Enforce secure SNMP and management-plane settings on Cisco IOS and IOS XE devices. Review device and management logs for configuration changes and suspicious SNMP activity. | ||
Practitioner Guidance
What to prioritise: Confirm whether any Cisco IOS or IOS XE systems are still reachable through the vulnerable SNMP path, then treat those devices as high priority if they are exposed to untrusted networks or broad administrative access. For infrastructure flaws like this, exposure and asset criticality matter more than whether a successful exploit has already been observed in your environment.
What to verify: Validate patch status against the vendor advisory, then verify that management access is limited to approved sources and that logging is sufficient to spot changes in configuration or session behaviour. If you cannot verify who can reach the management plane, you do not yet know whether the vulnerability is meaningfully contained.
Practitioner takeaway: For a KEV-listed network device flaw, the practical decision is to treat exposure as an incident-prevention problem, not just a patch ticket, because confirmed exploitation means the control question is “what can still be reached?” rather than “is there a fix?”
Related resources from NHI Mgmt Group
- Is CVE-2017-6743 (Cisco IOS and IOS XE Software SNMP Remote Code Execution) being exploited in the wild?
- Is CVE-2017-6740 (Cisco IOS and IOS XE Software SNMP Remote Code Execution) being exploited in the wild?
- Is CVE-2017-6739 (Cisco IOS and IOS XE Software SNMP Remote Code Execution) being exploited in the wild?
- Is CVE-2017-6737 (Cisco IOS and IOS XE Software SNMP Remote Code Execution) being exploited in the wild?
Deepen Your Knowledge
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.
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