HowToFixMe
● High · CVSS 8.8 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2017-6737: Buffer overflow in IOS

⚡ At a glance
Severity8.8 (High)
Actively exploited?Yes, listed in CISA KEV (added 2022-03-03)
AffectedCisco IOS 12.1(3)XI, 12.2(4)B, 12.2(15)B, 12.2(16)B1, 12.2(4)B7, 12.2(4)B2, 12.2(16)B2, 12.2(4)B6, 12.2(4)B1, 12.2(4)B4, 12.2(4)B3, 12.2(4)B8, 12.2(4)B5, 12.2(16)B, 12.2(2)XA, 12.2(2)XA2, 12.2(2)XA3, 12.2(2)XA4, 12.2(2)XA5, 12.2(2)XA1, 12.2(2)XB11, 12.2(2)XB5, 12.2(2)XB2, 12.2(2)XB1, 12.2(2)XB10, 12.2(2)XB7, 12.2(2)XB3, 12.2(2)XB6, 12.2(2)XB14, 12.2(2)XB12, 12.2(2)XB15, 12.2...
Fixed inNo single fixed build, run the Cisco Software Checker on advisory cisco-sa-20170629-snmp for your platform and train
Type (CWE)CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer (authenticated SNMP buffer overflow → RCE or device reload)

Exploitation status

CVE-2017-6737 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Cisco IOS and IOS XE Software SNMP Remote Code Execution Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: although a public exploit is not directly linked in this CVE’s primary references, its place on the CISA KEV catalog confirms working attack code is in active use in the wild. treat weaponization as certain and patch on an emergency timeline.

Authoritative references:

WARNING: This vulnerability is on the CISA Known Exploited Vulnerabilities catalog (added 2022-03-03). Federal civilian agencies must remediate by 2022-03-24. Treat it as active exploitation, not theoretical.

What is CVE-2017-6737?

CVE-2017-6737 is a buffer overflow in the SNMP subsystem of Cisco IOS and IOS XE Software. A crafted SNMP packet sent to an affected router overruns a buffer in the code that parses SNMP requests. Depending on how the overflow lands, the result is one of two things: the device reloads (a denial of service that drops every interface on that box), or the attacker executes arbitrary code and takes full administrative control of the router. Cisco's record and CISA both note the technical impact as total, this is not a read-only information leak, it is a path to owning the control plane of the device.

The flaw is classified as CWE-119, Improper Restriction of Operations within the Bounds of a Memory Buffer. It carries a CVSS 3.0 base score of 8.8 (High) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Read that vector carefully, because it explains the one real precondition: PR:L means the attacker needs low privileges, not none. To exploit this, the attacker must already hold a valid SNMP read-only community string (for SNMPv1 or v2c) or valid SNMPv3 user credentials. SNMP version does not matter: versions 1, 2c, and 3 are all affected.

That credential requirement is thinner than it sounds. Plenty of production routers still run SNMP with default community strings like public or private, or with a string that was shared across the whole fleet and never rotated. Anyone who can reach UDP/161 on the device and guess or sniff that string can reach the vulnerable code. The mitigating factor is that only traffic directed at the affected system can trigger it; this cannot be exploited in transit. So the entire defense comes down to who can send SNMP to the box, and whether the SNMP engine still parses the vulnerable OIDs.

This CVE is on the CISA Known Exploited Vulnerabilities catalog (added 2022-03-03), so working attack code is in circulation. The exploitation status and remediation deadline are covered in the Exploitation status section above.

Am I affected? Check your IOS train

This bug lives in Cisco IOS and IOS XE only. There is no equivalent in FortiOS, PAN-OS, or Junos, if you are running one of those, this CVE does not apply to you. On the Cisco device itself, get the running train from the CLI:

# Cisco IOS / IOS XE. confirm the running train
show version | include Version
show version | include IOS

# List what SNMP is currently exposing (this is what matters most)
show running-config | include snmp-server
show snmp community

The affected list spans an enormous range of 12.x trains (see the Affected row above, 12.1(3)XI through the 12.4 family and many XE builds). Because the bug touches so many trains, matching a static version string by hand is unreliable. The authoritative way to confirm exposure is the Cisco Software Checker tied to advisory cisco-sa-20170629-snmp: enter your exact platform and running build and it returns whether you are affected and the first fixed release for your train.

The more important signal is the second pair of commands. If show snmp community returns nothing and show running-config | include snmp-server is empty, SNMP is disabled and the attack surface is closed regardless of IOS version. If SNMP is configured, you are exposed until you either upgrade or apply the OID-exclusion workaround below.

How to fix CVE-2017-6737

The permanent fix is to upgrade IOS or IOS XE to a build that contains the SNMP buffer-overflow fix. Cisco did not publish one universal fixed version in this CVE record because the correction shipped across many different trains. Do not guess a fixed build. Use the Cisco Software Checker on advisory cisco-sa-20170629-snmp to get the first fixed release for your exact platform and train, then upgrade to that release or later.

Upgrade the IOS / IOS XE image

Once the Software Checker gives you a target build, stage the image and reload during a maintenance window. The control-plane reload drops traffic, so plan it.

# Vendor advisory: cisco-sa-20170629-snmp
enable
show version | include Version            ! record the current build
dir flash:                                ! confirm free space for the new image

! copy the verified image from your file server
copy tftp: flash:                         ! or: copy scp: flash:  /  copy ftp: flash:

! verify the image hash matches what Cisco published before booting it
verify /md5 flash:<fixed-image>.bin

configure terminal
boot system flash:<fixed-image>.bin
end
copy running-config startup-config
reload                                     ! reboots onto the fixed image

After the reload, run show version | include Version and confirm the build matches the fixed release from the Software Checker. On dual-supervisor or stackable platforms, follow the platform's ISSU or stack-upgrade procedure so you are not running a mixed-version control plane longer than necessary.

If you can't reload the router yet

This is Cisco's documented interim workaround for cisco-sa-20170629-snmp, and it is the correct one for this CVE: deny SNMP access to the affected MIBs by binding an SNMP view that excludes the vulnerable object groups, then re-bind your community strings and SNMPv3 groups to that restricted view. A device that never parses the vulnerable OIDs cannot be driven into the overflow through them.

# Cisco IOS: exclude the affected MIB OID groups from an SNMP view,
# then bind communities/users to that view so the vulnerable OIDs are unreachable.
configure terminal

! create a restricted view that starts from everything, then excludes the affected groups
snmp-server view NO_VULN_OIDS iso included
snmp-server view NO_VULN_OIDS ciscoMgmt excluded
! (use the exact OID groups Cisco lists in cisco-sa-20170629-snmp for your image)

! re-bind read-only community to the restricted view
snmp-server community <your-ro-string> view NO_VULN_OIDS RO 99

! for SNMPv3, bind the group to the restricted view
snmp-server group RESTRICTED v3 priv read NO_VULN_OIDS

end
copy running-config startup-config

Pair that with a hard access control so only your management subnet can reach SNMP at all. Even on a patched router this is good hygiene; on an unpatched one it shrinks the attacker population to hosts on a trusted segment.

# Restrict SNMP (UDP/161) to a trusted management subnet
configure terminal
access-list 99 remark SNMP managers only
access-list 99 permit 10.10.0.0 0.0.255.255
! bind the ACL to every community / SNMPv3 group
snmp-server community <your-ro-string> view NO_VULN_OIDS RO 99
end
copy running-config startup-config

If SNMP is not actually needed on a given device, the cleanest interim control is to turn it off entirely until the image is upgraded:

# Remove SNMP completely where it is not required
configure terminal
no snmp-server
end
copy running-config startup-config

None of these workarounds remove the buffer overflow. They remove the reachable path to it. Treat them as a bridge to the image upgrade, not a substitute for it: CISA records this CVE as actively exploited, so the upgrade should still happen on an emergency timeline.

Verify the fix

After upgrading, confirm three things on the device itself:

# 1. Running build is the fixed release from the Software Checker
show version | include Version

# 2. The device actually rebooted onto the new image (not the old boot variable)
show boot
show version | include System image file

# 3. SNMP is back to your intended, restricted configuration
show running-config | include snmp-server
show snmp view

Expected result: the reported version is at or above the fixed release Cisco lists for your platform, the active system image file points at the new .bin, and SNMP is exposed only through your restricted view and management ACL. If you applied the OID-exclusion workaround as a bridge, you can leave it in place after the upgrade, it does no harm and tightens SNMP exposure either way.

References

Written by Sai Kiran Pandrala on 2026-05-25. Always confirm against the vendor's advisory before applying changes in production.

Additional nearby issues sensible to fix in the same maintenance window:

People also ask

Can an attacker exploit CVE-2017-6737 without any credentials?

No. The attacker must already know a valid SNMP read-only community string (SNMPv1/v2c) or valid SNMPv3 user credentials. the CVSS vector lists PR:L, low privileges required. But default or unrotated community strings such as public or private make that bar trivial to clear, which is why the flaw still rates CVSS 8.8.

Does CVE-2017-6737 give code execution or just a crash?

Both outcomes are possible. The SNMP buffer overflow can reload the router (a denial of service) or, with a crafted SNMP packet, let the attacker run arbitrary code and obtain full control of the device. CISA records the technical impact as total.

What is the fixed Cisco IOS version for CVE-2017-6737?

There is no single fixed version, the correction shipped across many IOS and IOS XE trains. Use the Cisco Software Checker on advisory cisco-sa-20170629-snmp to find the first fixed build for your exact platform and train. Until you can upgrade, apply the OID-excluding SNMP view workaround.

How do I mitigate CVE-2017-6737 if I can't reload the router yet?

Bind an SNMP view that excludes the vulnerable OIDs from the affected MIBs, and restrict SNMP (UDP/161) to a trusted management subnet with an ACL. This is Cisco's documented interim workaround. It does not remove the bug; it removes the reachable path until you can load a fixed image.