Cisco IOS XE Software Simple Network Management Protocol Denial of Service Vulnerability

🚨SEVERITY: HIGH — CVSS 7.7Security Advisory

TL;DR 📌

  • A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco IOS XE Software could allow an authenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to improper error handling when parsing a specific SNMP request. An attacker could exploit this vulnerability by sending…
  • Highest CVSS: 7.7 (High).
  • Check the advisory for fixed releases — remediation detail is in the vendor link below.
  • CVEs: CVE-2025-20312.

What it is

CVE-2025-20312 is a denial-of-service flaw in the SNMP subsystem of Cisco IOS XE Software. It’s caused by improper error handling when the device parses a specific SNMP request, and it affects SNMP versions 1, 2c, and 3.

Exploitation requires authentication: an attacker needs a valid SNMP community string (read-write or read-only) to exploit it via SNMPv1 or v2c, or valid SNMP user credentials to exploit it via SNMPv3. Given valid credentials, the attacker sends a crafted SNMP request over the network, which triggers an unexpected reload of the device — a DoS condition, not code execution or data compromise.

The flaw only applies where two conditions are both met: the device is a Cisco switch running vulnerable IOS XE, and it has weighted early random detection (WRED) for MPLS EXP configured (visible as random-detect mpls-exp-based under an applied policy-map), with SNMP enabled. Cisco IOS XE routing platforms don’t support WRED for MPLS EXP and are therefore not affected. IOS, IOS XR, and NX-OS are also confirmed not vulnerable. Cisco PSIRT states it is not aware of any public announcements or malicious use of this vulnerability, and it is not in CISA’s KEV catalogue.

What to do

  • Check exposure with show running-config for random-detect mpls-exp-based under an applied policy-map, and check SNMP status with show running-config | include snmp-server community (v1/v2c) and show running-config | include snmp-server group plus show snmp user (v3). If WRED for MPLS EXP is not configured, the device isn’t affected.
  • There is no workaround, but Cisco describes a mitigation: create an SNMP view that excludes the vulnerable OID (cbQosREDClassStatsEntry), alongside standard SNMP security views excluding snmpUsmMIB, snmpVacmMIB, and snmpCommunityMIB. Test this in your environment before deploying, as it may affect SNMP-based monitoring of QoS/WRED stats.
  • Restrict SNMP access to trusted management hosts only, regardless of whether you apply the mitigation.
  • Use the Cisco Software Checker against your running release to identify the fixed release for this advisory; the advisory does not list specific fixed version numbers in the summary text, so run the check per-device rather than assuming a single target version.
  • Treat this as one advisory within Cisco’s September 2025 semiannual IOS/IOS XE bundled publication — if you’re patching for this CVE, check the bundle for other advisories that may apply to the same devices at the same time.

For leadership 🧭

Executive summary. Cisco switches running IOS XE with WRED for MPLS EXP and SNMP enabled can be forced to reload by anyone holding valid SNMP credentials, causing an outage rather than data loss. There’s no exploitation reported and no KEV listing, so this can go through normal change control rather than an emergency patch.

Why it matters:

  • Only Cisco switches running IOS XE with random-detect mpls-exp-based configured under an applied policy-map and SNMP enabled are affected; IOS XE routers, IOS, IOS XR and NX-OS are confirmed not vulnerable.
  • Exploitation needs a valid SNMP v1/v2c community string or v3 user credentials, so the risk is tied directly to who holds SNMP access, not to unauthenticated network exposure.
  • A successful crafted SNMP request causes the switch to reload unexpectedly, meaning a denial-of-service outage on production switching infrastructure, not code execution or data theft.
  • There is no workaround, only a mitigation (excluding the cbQosREDClassStatsEntry OID via an SNMP view), so remediation ultimately depends on getting to a fixed IOS XE release.

Now / Next / Later:

  • Now: Run show running-config for random-detect mpls-exp-based under an applied policy-map alongside the SNMP community/group/user checks to identify which switches are actually exposed.
  • Next: On exposed switches, deploy the SNMP view mitigation to exclude the cbQosREDClassStatsEntry OID after testing it doesn’t disrupt WRED/QoS monitoring, and confirm SNMP access is restricted to trusted management hosts.
  • Later: Use the Cisco Software Checker to identify and schedule upgrades to the fixed IOS XE release for each affected switch, and review SNMP credential management as part of routine device hardening.

Source