Cisco IOS and IOS XE Software, SNMP stack-based buffer overflow

Overview

CVE-2025-20352 is a stack-based buffer overflow (CWE-121) in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS Software and Cisco IOS XE Software. Cisco published advisory cisco-sa-snmp-x4LPhte on September 24, 2025, with a CVSS 3.1 base score of 7.7 (High). Cisco's Product Security Incident Response Team (PSIRT) confirmed that the vulnerability was exploited in the wild after local administrator credentials were compromised, and CISA added it to the Known Exploited Vulnerabilities catalog on September 29, 2025 with a federal remediation due date of October 20, 2025. The issue affects Cisco IOS XR and NX-OS only by exclusion: those platforms are not affected. All versions of SNMP are in scope wherever SNMP is enabled.

Technical Details

The vulnerability is caused by improper bounds checking when the SNMP engine parses certain crafted SNMP messages, leading to a stack overflow in the SNMP subsystem. An attacker triggers it by sending specially crafted SNMP packets to an affected device over IPv4 or IPv6. The privilege required depends on the desired outcome. For a denial of service, the attacker needs an SNMPv2c or earlier read-only community string, or valid SNMPv3 user credentials, and is treated as a low-privileged attacker; the result is that the affected device reloads, causing an outage. For remote code execution, which applies to Cisco IOS XE Software, the attacker needs an SNMPv1 or v2c read-only community string or valid SNMPv3 credentials in addition to administrative or privilege 15 credentials, and executes code as the root user, leading to full system compromise. The NVD/Cisco CVSS vector AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H reflects a network-reachable, low-complexity attack requiring low privileges, with a changed scope and a High availability impact (the score is anchored to the DoS outcome). Cisco notes there are no workarounds; the only mitigations are upgrading or restricting SNMP exposure.

Impact

• Denial of service: an authenticated low-privileged attacker can crash an affected device and force a reload, disrupting network connectivity.
• Remote code execution as root on Cisco IOS XE when the attacker also possesses administrative/privilege 15 credentials, resulting in complete device compromise.
• Confirmed active exploitation in the wild following compromise of local administrator credentials (Cisco PSIRT); listed in the CISA KEV catalog.
• Broad attack surface: any IOS or IOS XE device with SNMP enabled is affected, including Meraki MS390 and Catalyst 9300 switches running Meraki CS 17 and earlier.
• Network availability impact is rated High; confidentiality and integrity are rated None in the CVSS base vector, though successful RCE clearly extends beyond availability in practice.

Mitigation

1. Upgrade Cisco IOS XE Software to Release 17.15.4a or later, which is the fixed release identified by Cisco for the primary IOS XE track.
2. For Cisco IOS Software, upgrade to a fixed release on your train: 15.2(7)E13, 15.2(8)E8, 15.5(1)SY16, or 15.9(3)M1 or later as applicable. Use the Cisco Software Checker for cisco-sa-snmp-x4LPhte to confirm the exact first-fixed release for your specific platform and train.
3. There are no workarounds. As an interim risk-reduction measure only, restrict SNMP access to trusted management hosts using ACLs, and disable SNMP on devices that do not require it.
4. As an additional interim measure, exclude the affected object IDs (OIDs) from SNMP views; a device should still be considered vulnerable unless the affected OIDs have been explicitly excluded or the software has been upgraded.
5. Rotate SNMP community strings and SNMPv3 credentials, and protect administrative/privilege 15 credentials, since RCE requires their compromise.

Detection

Start by determining whether SNMP is enabled and how it is exposed. On the device, review the running configuration for snmp-server statements, configured community strings, SNMPv3 users and views, and any snmp-server host targets. Cisco provides CLI verification commands in the advisory; confirm whether the affected OIDs are excluded from all configured SNMP views, because a device without that exclusion (and without the fixed software) must be treated as vulnerable. Identify your running version with show version and compare it against the fixed releases (IOS XE 17.15.4a; IOS 15.2(7)E13, 15.2(8)E8, 15.5(1)SY16, 15.9(3)M1) using the Cisco Software Checker for your exact platform.

For network detection, Cisco and Talos published Snort signature SID 65356 to detect exploitation attempts; ensure this rule is deployed and alerting on inline or IDS sensors that see SNMP traffic (UDP 161/162). Because exploitation requires SNMP reachability, instrument the network to flag SNMP packets sourced from anything other than your authorized network-management stations. Unexpected SNMP traffic to infrastructure devices from user subnets, or from external addresses over IPv4 or IPv6, is a strong early indicator and should be alerted on at firewalls and flow collectors (NetFlow/IPFIX).

On the device side, the most reliable symptom of the denial-of-service path is an unexplained device reload. Collect and centralize syslog, and alert on crash and reload events, %SNMP-related errors, and unexpected SYS-5-RELOAD messages; retrieve and preserve any crashinfo files for forensic review, as a stack overflow in the SNMP process will typically leave a crash artifact. For the RCE path on IOS XE, monitor for signs of post-exploitation: configuration changes you did not authorize, new local accounts or privilege escalations, unexpected enabling of services, and anomalous management-plane logins around the time of suspicious SNMP activity. Correlate AAA/TACACS+ logs for use of administrative or privilege 15 accounts from unusual sources, since RCE depends on those credentials.

Given confirmed in-the-wild exploitation and the September 29, 2025 CISA KEV listing (remediation due October 20, 2025), treat any unpatched, SNMP-enabled IOS or IOS XE device as a priority. Retro-hunt syslog and flow data back to at least the September 24, 2025 disclosure date for the indicators above, and prioritize internet-exposed and management-network devices for both patching and log review.