Cisco IOS and IOS XE Software SNMP Denial of Service and Remote Code Execution Vulnerability

🚨 SEVERITY: HIGH — CVSS 7.7 Security Advisory

TL;DR 📌

A vulnerability in the SNMP subsystem of Cisco IOS and IOS XE Software could allow authenticated attackers to cause a denial of service (DoS) or execute arbitrary code. This affects devices with SNMP enabled. Immediate action is required to patch or mitigate this vulnerability.

What happened 🕵️‍♂️

A vulnerability has been identified in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS and IOS XE Software. This vulnerability allows an authenticated remote attacker to cause a denial of service (DoS) condition or execute code as the root user on affected devices. The exploitation requires valid SNMP credentials, either through SNMPv2c read-only community strings or SNMPv3 user credentials. This vulnerability is due to a stack overflow condition in the SNMP subsystem.

Affected products 🖥️

The vulnerability affects Cisco devices running vulnerable releases of Cisco IOS Software and Cisco IOS XE Software. Specifically, it impacts:

  • Meraki MS390
  • Cisco Catalyst 9300 Series Switches running Meraki CS 17 and earlier

Note: All devices with SNMP enabled and not explicitly excluding the affected object ID (OID) are considered vulnerable.

Fixed software 🔧

Upgrade to the first fixed release in your train (or later):

Release / Product First Fixed Release Notes
1.0 Initial public release.
Cisco IOS and IOS XE Software Not specified

Workarounds 🧯

There are no workarounds that fully address this vulnerability. However, a mitigation strategy includes:

  • Allowing only trusted users to have SNMP access.
  • Monitoring affected systems using the show snmp host command.
  • Disabling the affected OIDs on devices where applicable.

Implementing these mitigations may impact device management through SNMP.

Risk in context 🎯

The highest CVSS score for this vulnerability is 7.7, categorizing it as High risk. The exposure is significant since it requires only authenticated access, making it easier for attackers with valid credentials to exploit the vulnerability. The potential for denial of service or remote code execution poses a serious threat to network integrity and availability.

Fast facts ⚡

  • CVSS Score: 7.7 (High)
  • Attack Vector: Remote, requires authentication
  • Impact: Denial of service, remote code execution
  • SNMP Versions Affected: All versions of SNMP
  • Exploitation: Successful exploitation has been observed in the wild.

For leadership 🧭

Executive summary. Any switch or router running IOS or IOS XE with SNMP turned on – including Meraki MS390 and Catalyst 9300 switches on Meraki CS 17 and earlier – can be knocked offline or fully compromised by someone who already holds SNMP read credentials. Because there is no complete workaround, this needs a patching plan this week, not just a configuration tweak.

Why it matters:

  • The flaw is a stack overflow in the SNMP subsystem itself, so a successful trigger can hand an attacker root-level code execution on the device, not just a crash.
  • Only SNMP access is needed – an SNMPv2c read-only community string or an SNMPv3 user – and these are frequently shared across a fleet or left at defaults on production network gear.
  • Confirmed affected products include Meraki MS390 switches and Cisco Catalyst 9300 Series Switches running Meraki CS 17 and earlier, but Cisco states any device with SNMP enabled and the vulnerable OID not excluded is exposed.
  • Cisco has no workaround that fully closes the hole; the available mitigations (restricting SNMP access, disabling the affected OIDs) reduce risk but degrade SNMP-based monitoring and management.

Now / Next / Later:

  • Now: Identify every IOS and IOS XE device with SNMP enabled and check, via ‘show snmp host’ and OID review, whether the affected OID is exposed and who holds valid community strings or SNMPv3 credentials.
  • Next: In the next change window, restrict SNMP access to a small, trusted set of management hosts, disable the affected OID where it isn’t operationally required, and schedule the upgrade to the first fixed release for each affected train.
  • Later: Move SNMPv2c community strings and SNMPv3 credentials onto a rotation schedule and bring SNMP access under the same access-control review as other privileged management protocols on network gear.