Remediation Guides

How to Fix cisco-sa-20170629-snmp (CVE-2017-6742) on Cisco IOS and IOS XE

26 September 2026 8 min read

The cisco-sa-20170629-snmp finding means a Cisco IOS or IOS XE device runs a release affected by nine SNMP buffer overflows, including the actively exploited CVE-2017-6742. An attacker who knows a read-only community string or SNMPv3 credentials can reload or take over the device. Fix it by upgrading; until then, exclude the affected MIBs and restrict SNMP by ACL.

What the scanner is actually detecting

Nessus reports this as Cisco IOS SNMP Packet Handling Remote Buffer Overflow Multiple RCE (cisco-sa-20170629-snmp), plugin ID 101268, in the CISCO family, rated High (CVSS v3 base score 8.8). IOS XE devices are covered by a sibling plugin titled Cisco IOS XE SNMP Packet Handling Remote Buffer Overflow Multiple RCE (cisco-sa-20170629-snmp) with the same solution. Both map to one Cisco advisory that covers CVE-2017-6736 through CVE-2017-6744; CVE-2017-6742 is Cisco bug CSCve54313.

Two details decide how you should read the result:

  • It is version based. The plugin needs the Host/Cisco/IOS/Version knowledge base item, which Nessus collects when it can identify the device’s software release (usually through a credentialed SSH scan). It compares that release against the advisory and sends no exploit traffic.
  • It only runs in paranoid mode. The plugin also requires Settings/ParanoidReport, so it appears only when the scan policy reports potential flaws that Nessus cannot fully confirm. Read it as “this release is affected,” not “this device is exploitable right now.”

Cisco says SNMP versions 1, 2c and 3 are all affected, over IPv4 or IPv6, and only traffic directed to the device can trigger the bugs. The vulnerable code sits in these MIBs, which Cisco says are all enabled by default whenever SNMP is enabled: ADSL-LINE-MIB, ALPS-MIB, CISCO-ADSL-DMT-LINE-MIB, CISCO-AUTH-FRAMEWORK-MIB, CISCO-BSTUN-MIB, CISCO-MAC-AUTH-BYPASS-MIB, CISCO-SLB-EXT-MIB, CISCO-VOICE-DNIS-MIB, CISCO-VOICE-NUMBER-EXPANSION-MIB and TN3270E-RT-MIB. Cisco added CISCO-AUTH-FRAMEWORK-MIB to the workaround in July 2025, so older copies of the workaround and the Nessus solution text do not list it.

Real-world risk

This is a known-exploited bug. Cisco PSIRT reports exploitation of eight of the nine CVEs, and all eight are in the CISA Known Exploited Vulnerabilities catalog; CVE-2017-6742 was added on 19 April 2023 (see how the CISA KEV catalog works). That addition followed a joint advisory from the UK NCSC, NSA, CISA and FBI describing APT28 exploiting CVE-2017-6742 in 2021. Weak community strings, including the default “public”, gave the group access to routers that accepted SNMPv2 requests, and on some devices it deployed malware called Jaguar Tooth.

Actual exposure depends on three things:

  • Credentials. The attacker needs the read-only community string (v1 or v2c) or valid SNMPv3 user credentials. A default or guessable string makes that trivial, and v2c sends the string in cleartext.
  • Reachability. A device that answers SNMP only from a few management hosts is far harder to reach than one that answers from any subnet.
  • Impact. Success gives code execution and full control of the device; a failed attempt usually reloads it, causing an outage.

How to confirm it on the device

Record the release and check whether SNMP is configured at all. If the second command prints nothing, the SNMP agent is not configured:

show version
show running-config | include snmp-server

Then see who can query the agent:

show snmp community
show snmp group

Cisco’s command reference states that a community string permits read-only access to all objects unless you attach a view, so any snmp-server community line without the view keyword exposes the vulnerable MIBs. An SNMPv3 group with no read view can likewise read the entire Internet OID subtree (1.3.6.1). Do not use show snmp mib as proof of safety: Cisco warns that some affected MIBs are enabled without appearing in its output.

From a Linux host with the Net-SNMP tools, test whether the device answers a default string (1.3.6.1.2.1.1.1.0 is sysDescr):

snmpget -v2c -c public 192.0.2.1 1.3.6.1.2.1.1.1.0

A reply means anyone who can reach UDP 161 already holds the credential this exploit needs. Cisco also notes that exploitation reloads the device and writes a crashinfo file, so an unexplained reload in show version is worth having Cisco TAC review.

How to fix it

Option 1: disable SNMP where nothing uses it

If no monitoring system polls the device, remove the agent. Per Cisco’s command reference, no snmp-server disables SNMPv1, v2c and v3:

configure terminal
 no snmp-server
 end
copy running-config startup-config

Option 2: apply the MIB exclusion workaround

If you need SNMP, build the view from Cisco’s advisory. This is Cisco’s current list, including the 2025 addition:

configure terminal
snmp-server view NO_BAD_SNMP iso included
snmp-server view NO_BAD_SNMP internet included
snmp-server view NO_BAD_SNMP snmpUsmMIB excluded
snmp-server view NO_BAD_SNMP snmpVacmMIB excluded
snmp-server view NO_BAD_SNMP snmpCommunityMIB excluded
snmp-server view NO_BAD_SNMP ciscoMgmt.252 excluded
snmp-server view NO_BAD_SNMP transmission.94 excluded
snmp-server view NO_BAD_SNMP mib-2.34.9 excluded
snmp-server view NO_BAD_SNMP ciscoMgmt.35 excluded
snmp-server view NO_BAD_SNMP ciscoMgmt.95 excluded
snmp-server view NO_BAD_SNMP ciscoMgmt.130 excluded
snmp-server view NO_BAD_SNMP ciscoAuthFrameworkMIB excluded
snmp-server view NO_BAD_SNMP ciscoMgmt.219 excluded
snmp-server view NO_BAD_SNMP ciscoMgmt.254 excluded
snmp-server view NO_BAD_SNMP ciscoMabMIB excluded
snmp-server view NO_BAD_SNMP ciscoExperiment.997 excluded

A view protects nothing until every community and every SNMPv3 group uses it. In the same change, restrict SNMP to your management stations with a standard ACL and replace any default or guessable string. Add the new community before removing the old one so monitoring can switch over without a gap:

access-list 10 permit 192.0.2.10
access-list 10 permit 192.0.2.11
access-list 10 deny any log
snmp-server community <new-random-string> view NO_BAD_SNMP RO 10
! once the NMS uses the new string:
no snmp-server community public
no snmp-server community <old-string>

Community strings are limited to 32 characters with no spaces, and Cisco says to avoid the @ symbol. For SNMPv3, re-enter each existing group with the view and ACL, keeping its current security level:

snmp-server group v3group v3 priv read NO_BAD_SNMP access 10
 end
copy running-config startup-config

Cisco’s example also sets write NO_BAD_SNMP; add a write view only if the group really needs write access. The NCSC advisory further recommends retiring SNMPv1 and v2c in favor of SNMPv3 where possible.

Option 3: upgrade to a fixed release (the real fix)

The workaround mitigates; only the upgrade removes the vulnerable code. Cisco publishes fixed releases through the Cisco IOS Software Checker, so enter your exact release there to find the first fixed release for your train. For a classic IOS router that boots a single image file, a typical sequence is:

copy running-config flash:pre-upgrade.cfg
copy tftp://192.0.2.50/<fixed-image>.bin flash:
verify /md5 flash:<fixed-image>.bin
configure terminal
 no boot system
 boot system flash:<fixed-image>.bin
 boot system flash:<current-image>.bin
 end
copy running-config startup-config
reload

Compare the MD5 value with the one on Cisco’s download page. IOS XE switches running in install mode use the upgrade procedure in their platform release notes instead. If the hardware is end of life and no fixed release exists, keep the workaround and ACL, record an exception, and plan replacement; see our guide to handling a KEV entry you cannot patch.

How to verify the fix and rescan

  1. show version reports a release the Software Checker lists as fixed.
  2. show running-config | include snmp-server shows every community with view NO_BAD_SNMP and an ACL, and no public, private or other default string.
  3. show snmp group shows NO_BAD_SNMP as the read view for each group you configured.
  4. From a host outside the ACL, the snmpget test above times out, while your NMS still polls normally.
  5. Rescan with the same credentials and paranoid setting. Plugin 101268 should clear once the release is fixed. If you applied only the workaround, expect it to stay open and record it as mitigated with an expiry date.

What can break and how to roll back

  • Excluded MIBs. Polling of DSL line data, voice DNIS and number expansion, MAC authentication bypass, authentication sessions, server load balancing and TN3270 stops returning values. Check your NMS templates first. To roll back, re-enter the community without the view (snmp-server community <string> RO 10) and remove it with no snmp-server view NO_BAD_SNMP.
  • The ACL. Any poller not listed, such as a backup collector, loses access. The log keyword on the deny line shows who is dropped; add missing addresses to access list 10.
  • New community strings. Every tool that polls the device must be updated, so run old and new strings side by side briefly.
  • no snmp-server. This stops all SNMP versions. Roll back by restoring your saved snmp-server lines.
  • The upgrade. It reloads the device, so schedule a window and confirm memory and feature support first. Because the old image stays as the second boot system entry, you can roll back by making it the first entry again and reloading.

Common false positive reasons

  • Workaround in place. A version-based check still flags a device whose communities and groups all use the exclusion view. That is mitigated, not false: the vulnerable code remains.
  • SNMP disabled. With no snmp-server lines the flaw cannot be reached, yet the release is still affected. Record it as not exploitable in the current configuration.
  • Stale version data. Results collected before a reload show the old release. Rescan after the upgrade completes.
  • Release interpretation. If the Software Checker says your exact release is fixed and the scanner disagrees, keep the checker output as evidence and raise it with Tenable.

FAQ

Is SNMPv3 immune to CVE-2017-6742?

No. Cisco lists SNMPv1, v2c and v3 as affected. SNMPv3 only raises the bar, because the attacker needs valid user credentials instead of a community string.

Does changing the community string fix the vulnerability?

No. Anyone who learns the new string can still exploit an unpatched device. Pair it with the exclusion view and an ACL, then upgrade.

Why does plugin 101268 stay open after I applied the workaround?

The check compares the reported release with the advisory, so an affected release keeps the finding open. Close it by upgrading, or document it as mitigated.

Can show snmp mib prove I am not exposed?

No. Cisco says some affected MIBs are enabled without appearing in that output and recommends applying the entire exclusion list.

Tracking this finding across many devices

Across many routers and switches, the hard part is knowing which devices are upgraded, which are only mitigated and which await replacement. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export and supports per-finding retest for Nessus findings, so you can confirm plugin 101268 closes after each upgrade. Its AI triage can suggest false positives with evidence, and a human makes the final decision.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing
← All articles