Resources/Advisory

CVE-2025-20352: Cisco IOS and IOS XE SNMP stack overflow, exploited in the wild

A stack overflow in the SNMP subsystem of Cisco IOS and IOS XE lets an attacker with SNMP access cause a device reload, and with additional administrative credentials, execute code as root. Actively exploited before the patch.

2025-09-255 min readSecureBlock research team

Cisco disclosed CVE-2025-20352 on 24 September 2025 in the semiannual IOS bundle. The flaw is a stack overflow in the SNMP subsystem of Cisco IOS and IOS XE Software (CVSS 7.7) that can be triggered by a crafted SNMP packet over IPv4 or IPv6. All SNMP versions are affected (v1, v2c, v3). Cisco confirmed exploitation in the wild against devices where the attacker held valid administrator credentials.

What the flaw allows

The impact depends on the attacker's privilege level:

  • Denial of service. An attacker with an SNMPv2c (or earlier) read-only community string, or valid SNMPv3 user credentials, can send a crafted packet that reloads the device.
  • Remote code execution. An attacker who additionally holds administrative (privilege 15) credentials on the device can execute arbitrary code as the root user on the underlying OS.

The RCE path is realistic because SNMP community strings and administrative credentials are frequently stored together in monitoring stations and configuration management systems, and community strings are transmitted in plaintext for SNMPv1 and v2c.

$ snmpget -v2c -c <community> <target> <crafted-oid>

Exploit shape: a crafted SNMP request to any of the vulnerable OIDs. Cisco has not published the specific OID list to slow weaponisation.

Who is affected

  • Cisco IOS Software running SNMP on any version prior to the September 2025 fix train
  • Cisco IOS XE Software 17.9, 17.12, 17.15 prior to the corresponding maintenance release
  • Cisco IOS XR and NX-OS are not affected
  • Meraki-managed devices are not affected

An attacker needs a valid SNMPv2c community string or SNMPv3 credentials with read access. In practice, read-only community strings are widely reused and monitoring stations often expose them in plaintext, so the authentication requirement is a weak boundary.

How to check exposure

Confirm SNMP is running and enumerate configured communities and views:

Router# show running-config | include snmp-server
snmp-server community public RO
snmp-server community private RW 10
snmp-server host 10.10.10.5 version 2c public

Any community string in the running configuration means the device answers SNMP.

Check the software version against the fixed release matrix in the Cisco advisory:

Router# show version | include Software
Cisco IOS XE Software, Version 17.12.03

Compare against Cisco's fixed release table before assuming you are safe.

Review your monitoring station logs for SNMP polling from unexpected sources. Cisco's incident report noted the attacker preceded exploitation with reconnaissance from the same source that later delivered the payload.

What to do

  • Upgrade to the fixed IOS or IOS XE release listed in the Cisco advisory. Cisco published fixed builds across 17.9, 17.12 and 17.15 trains.
  • If you cannot upgrade immediately, restrict SNMP to a small ACL of monitoring hosts, or disable SNMP on devices that do not need it:
Router(config)# ip access-list standard SNMP-ONLY
Router(config-std-nacl)#  permit host 10.10.10.5
Router(config-std-nacl)#  deny   any log
Router(config)# snmp-server community REDACTED RO SNMP-ONLY

Minimum useful mitigation: SNMP only from monitoring stations, and log the denies.

  • Rotate every SNMP community string and SNMPv3 credential in the environment. Assume any credential that was in use before the patch is compromised.
  • Prefer SNMPv3 with authPriv over SNMPv2c going forward. Community strings travel unencrypted and get logged in packet captures.
  • Add this check to your continuous scan configuration; SecureBlock's platform reports exposed SNMP with community strings enumerated where safe.

Public tooling

At time of writing there is no Metasploit module and no template in the ProjectDiscovery Nuclei repository. Multiple proof-of-concept scripts and detection tools are published on GitHub — most trigger a device reload rather than achieving RCE, since the RCE path requires the additional privilege-15 credential.

  • Cisco PSIRT triage guide (linked below) is the authoritative check
  • Public GitHub PoCs — use only against your own lab devices

References

# Cisco Security Advisory
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snmp-x4LPhte

# NVD record
https://nvd.nist.gov/vuln/detail/CVE-2025-20352

# CISA KEV entry
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Primary references.

Want this checked against your environment?