Cisco IOS XE Software for Catalyst 9000 Series Switches Denial of Service Vulnerability

🚨SEVERITY: HIGH — CVSS 7.4Security Advisory

TL;DR 📌

  • A vulnerability in the handling of certain Ethernet frames in Cisco IOS XE Software for Catalyst 9000 Series Switches could allow an unauthenticated, adjacent attacker to cause an egress port to become blocked and drop all outbound traffic. This vulnerability is due to improper handling of crafted Ethernet frames. An attacker could exploit this vulnerability…
  • Highest CVSS: 7.4 (High).
  • Check the advisory for fixed releases — remediation detail is in the vendor link below.
  • CVEs: CVE-2025-20311.

What it is

CVE-2025-20311 is a denial of service vulnerability in Cisco IOS XE Software affecting Catalyst 9000 Series Switches. It sits in the handling of Ethernet frames at the switching layer, not in a management-plane service.

The issue is triggered by crafted Ethernet frames sent through an affected switch. Cisco describes the attacker as unauthenticated and adjacent — they need Layer 2 access to a port on the switch, not credentials or IP reachability. Affected ports are those configured as a trunk, a Cisco TrustSec-enabled port, or a MACsec-enabled port; the affected platforms are the Catalyst 9200, 9300, 9400, 9500 and 9600 Series Switches. Meraki MS390 and Catalyst 9300 switches running software earlier than Meraki CS 17.2.2 are also affected, as is Cloud-Managed Hybrid Operating Mode for Catalyst Wireless LAN Controllers running Cisco IOS XE releases earlier than 17.15.4 (fixed in 17.15.4).

A successful attack causes the egress port FIFO queue on the port to which the crafted frame is forwarded to get stuck, and that port stops forwarding any outbound traffic. This shows up as a continuously increasing “Total output drops” counter on the interface. The Catalyst 9800 Series Wireless Controllers, IE9300 Rugged Series Switches, and devices running IOS, IOS XR or NX-OS are confirmed not affected. Cisco PSIRT states it is not aware of any public announcements or malicious use of this vulnerability, and it is not listed in CISA’s Known Exploited Vulnerabilities catalogue.

What to do

  • Check the advisory’s Fixed Software section via the Cisco Software Checker against your running release; Cisco has released fixed software for this vulnerability, and for the Cloud-Managed Hybrid Operating Mode case, IOS XE 17.15.4 specifically addresses it.
  • There are no workarounds. Upgrading is the only remediation path.
  • Identify which of your Catalyst 9200/9300/9400/9500/9600 switches have a trunk port, a TrustSec-enabled port, or a MACsec-enabled port — these are the exposed configurations. Use show running-config | include switchport mode trunk|dynamic|dot1q-tunnel, show running-config | include cts manual, and show macsec summary to check.
  • Monitor interfaces for rising “Total output drops” counters as a sign of active impact.
  • If a port is affected, identify and remove the source of the crafted frames (block via VLAN or MAC ACL), then reload the device — Cisco states this is the only way to recover a stuck port.
  • Prioritise upgrades on switches with Meraki MS390/Catalyst 9300 combinations running software earlier than Meraki CS 17.2.2, as these are separately called out as affected.

For leadership 🧭

Executive summary. Catalyst 9200 through 9600 switches with trunk, TrustSec or MACsec ports can be knocked into a stuck-port state by anyone with Layer 2 access, no login required, silently dropping all outbound traffic until someone finds the offending device and reloads the switch. There’s no workaround, so this needs scheduling into the next patch cycle rather than left for the semiannual cycle to catch up on its own.

Why it matters:

  • The attacker doesn’t need credentials or IP reachability — just a cable or port on the same Layer 2 segment as a trunk, TrustSec, or MACsec-enabled interface on a Catalyst 9200/9300/9400/9500/9600 switch.
  • A successful frame jams the egress FIFO queue on the affected port, meaning outbound traffic silently drops while the interface counters climb — this can look like a hardware fault rather than an attack.
  • Recovery isn’t a config change: Cisco states the only fix once a port is stuck is finding and removing the source device, then reloading the switch, which means an outage window on production infrastructure.
  • Meraki MS390 and Catalyst 9300 combinations on Meraki CS releases before 17.2.2, and Cloud-Managed Hybrid Operating Mode WLCs before IOS XE 17.15.4, are separately called out as exposed and easy to miss in an inventory sweep.

Now / Next / Later:

  • Now: Run show running-config | include switchport mode trunk|dynamic|dot1q-tunnel, show running-config | include cts manual, and show macsec summary across your Catalyst 9200/9300/9400/9500/9600 fleet to identify which switches have an exposed port type.
  • Next: Use the Cisco Software Checker against each identified switch’s running release and schedule the upgrade to fixed IOS XE code (17.15.4 or later for Cloud-Managed Hybrid Operating Mode WLCs, and Meraki CS 17.2.2 or later for MS390/Catalyst 9300 pairs) in the next change window, since no workaround exists.
  • Later: Add a watch on ‘Total output drops’ interface counters for trunk, TrustSec and MACsec ports so a stuck queue is caught and traced to its source port quickly rather than mistaken for a hardware fault.

Source