On September 24, 2025, Cisco published advisory cisco-sa-snmp-x4LPhte disclosing CVE-2025-20352, a stack-based buffer overflow in the SNMP subsystem of Cisco IOS and IOS XE Software. Within forty-eight hours CISA had added the bug to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of October 20, 2025. The vulnerability carries a CVSS v3.1 score of 7.7, but the realistic impact ranges from a remote denial of service to full root-level code execution on IOS XE devices when the attacker holds privilege level 15 credentials. Because SNMP is enabled on the vast majority of carrier and enterprise routing infrastructure, the blast radius rivals the 2023 IOS XE Web UI catastrophe (CVE-2023-20198) that ushered in Salt Typhoon-class telco compromises.
What is the bug?
CVE-2025-20352 lives in the SNMP server's OID processing path. When the daemon walks a crafted Object Identifier sub-tree, a length field copied from the SNMP PDU is used without bounds checking against a fixed stack buffer. The result is a classical stack-smash: by sending a GetBulkRequest or GetNextRequest over SNMPv1, v2c, or v3 with a long, malformed varbind, an authenticated attacker can overwrite the saved return address. On legacy IOS the corruption causes a watchdog reset (denial of service); on IOS XE, the underlying Linux kernel runs the IOSd process as root, and a successful overwrite gives the attacker root-level command execution on the supervisor blade.
The bug class is CWE-121 (stack buffer overflow), the same class that wrecked Fortinet FortiGate in CVE-2024-21762 and FortiVoice in CVE-2025-32756 earlier the same year. What makes this instance especially painful is that SNMPv3 read-only users — often considered "safe" because they cannot configure the device — are sufficient to trigger the DoS path. Only the RCE path requires privilege 15.
How is it exploited?
Public exploitation began before the advisory shipped. Cisco TALOS attributed early activity to a cluster they track as "Operation Zero Disco," who chained CVE-2025-20352 with stolen TACACS+ secrets to land a persistent rootkit on Catalyst 9300 switches. The general pattern is:
# Conceptual SNMP varbind that triggers the overflow
# Real exploits embed the malicious OID inside a GetBulkRequest
from pysnmp.hlapi import *
community = CommunityData('public', mpModel=0) # SNMPv2c
target = UdpTransportTarget(('10.0.0.1', 161))
# Crafted sub-OID with oversized length field
malicious_oid = ObjectType(ObjectIdentity('1.3.6.1.4.1.9.9.' + 'A' * 4096))
for (errInd, errStat, errIdx, varBinds) in bulkCmd(
SnmpEngine(), community, target, ContextData(),
0, 25,
malicious_oid):
print(errInd, errStat, errIdx, varBinds)
In observed campaigns the attacker first compromises a TACACS+ or RADIUS server (often through a separate phishing chain) to obtain an SNMPv3 user with high privileges. They then SSH into a foothold host inside the management VLAN — exploitation across the public internet is rare because SNMP is usually filtered by ACLs at the edge. The payload disables logging via no logging host, writes a malicious EEM applet that re-enables the attacker's ACLs on every reboot, and exfiltrates the running configuration to a paste site over HTTPS.
Who is affected?
Every Cisco device running IOS or IOS XE with SNMP enabled and reachable from an attacker-accessible network is potentially vulnerable. Cisco enumerated the following fixed releases in the advisory:
- IOS XE 17.15.4a, 17.12.6, 17.9.7, 17.6.10
- IOS XE 16.12.13
- IOS 15.9(3)M11
Older IOS trains (15.2, 15.4) remain unpatched at the time of writing and Cisco's guidance is to disable SNMP entirely on those devices. Notably, Meraki MX and Catalyst SD-WAN appliances running cloud-managed firmware are not affected because they use a different SNMP stack.
The most exposed segments are: telco aggregation routers (ASR 1000, ASR 9000), enterprise core Catalyst 9300/9400/9500 switches, and any device where an SNMP read community string is shared across the fleet — because once one device is breached the credentials work everywhere.
What does patching require?
Patching is straightforward but disruptive: IOS XE upgrades require a reload and frequently a maintenance window for stateful switchover (SSO) pairs. Operators with hundreds of devices typically prioritize internet-edge routers first, then management-plane-exposed core devices, then access-layer switches behind segmented VLANs.
If immediate patching is not possible, the recommended workaround is to restrict SNMP access via a permit-list ACL and explicitly exclude the affected OID:
! Restrict SNMP to monitoring host only
access-list 99 permit host 10.10.10.50
access-list 99 deny any log
snmp-server community READ-ONLY RO 99
!
! Exclude the affected sub-tree from the view
snmp-server view SAFE iso included
snmp-server view SAFE 1.3.6.1.4.1.9.9 excluded
snmp-server community READ-ONLY view SAFE RO 99
This mitigation breaks legitimate monitoring of certain Cisco enterprise MIBs, so most teams accept that and schedule the patch.
How do you detect exploitation?
Three signals are highly indicative. First, SNMP traffic from non-monitoring source IPs hitting UDP/161 — a NetFlow query flow record contains snmp and src not in monitoring-net will surface this. Second, watch for IOS process crashes with IOS-3-SNMP_INPUT_QUEUE_OVERFLOW or SYS-3-CPUHOG immediately preceded by a large inbound SNMP packet. Third, the configuration archive should not show un-attributed changes; if it does, treat it as compromise.
A baseline Splunk SPL for SNMP anomaly:
index=network sourcetype=cisco:asa OR sourcetype=cisco:ios
| where dest_port=161 AND NOT (src_ip IN ("10.10.10.50","10.10.10.51"))
| stats count by src_ip, dest_ip
| where count > 100
For YARA on captured PCAPs, look for SNMP varbind length fields exceeding 1024 bytes:
rule cisco_snmp_oversized_oid {
strings:
$oid = { 30 ?? 02 01 [1-3] 04 ?? } // SNMP GetBulkRequest header
condition:
$oid and filesize > 1100
}
CISA's added detection guidance includes monitoring for unexpected system clock set commands in syslog, because the Operation Zero Disco operators reset the device clock to evade certificate validation when downloading their second-stage payload.
How Safeguard Helps
Safeguard ingests firmware SBOMs for Cisco IOS, IOS XE, NX-OS, and Meraki images and cross-references them against the live CISA KEV feed — when CVE-2025-20352 was added on September 25, 2025, every customer with an affected iosd build saw a critical finding within minutes. Reachability analysis powered by Griffin AI distinguishes devices where SNMP is bound to a restricted management VLAN from those where UDP/161 is reachable from untrusted networks, allowing security teams to prioritize the truly exposed devices first. Policy gates can block deployment of any network image below the fixed-release baseline, and VEX ingestion from Cisco PSIRT automatically suppresses findings on hardware models where the vulnerable code path is not compiled in. Combined with CMDB enrichment for SNMPv3 credential rotation tracking, Safeguard turns a 48-hour fleet-wide patching scramble into a triaged work queue.