Cisco IOS XR ARP Broadcast Storm Denial of Service Vulnerability

🚨SEVERITY: HIGH — CVSS 7.4Security Advisory

TL;DR 📌

  • A vulnerability in the Address Resolution Protocol (ARP) implementation of Cisco IOS XR Software could allow an unauthenticated, adjacent attacker to trigger a broadcast storm, leading to a denial of service (DoS) condition on an affected device. This vulnerability is due to how Cisco IOS XR Software processes a high, sustained rate of ARP traffic…
  • Highest CVSS: 7.4 (High).
  • Fix available — see the first fixed release below.
  • CVEs: CVE-2025-20340.

What it is

CVE-2025-20340 affects the ARP implementation in Cisco IOS XR Software. It is a denial of service issue, not a code execution or information disclosure flaw.

The problem lies in how IOS XR handles a high, sustained rate of ARP traffic arriving on the management interface. An adjacent, unauthenticated attacker who can send a large volume of ARP traffic to that interface can trigger a broadcast storm that overwhelms the device’s ARP processing. The result ranges from degraded performance to loss of management connectivity and complete unresponsiveness.

Exploitation requires network adjacency (CVSS vector AV:A) but no credentials or user interaction. Devices are only exposed if the management interface (MgmtEth 0/RP0/CPU0/0) is configured with an IP address and is in the “up” state — this can be checked with show interfaces MgmtEth 0/RP0/CPU0/0. Cisco notes that Local Packet Transport Services (LPTS) does not rate-limit or protect traffic received on management Ethernet interfaces, so there is no built-in throttling for this path.

Affected devices will show repeated log entries such as %PKT_INFRA-PQMON-6-QUEUE_DROP : Taildrop on XIPC queue 1 owned by arp as the ARP process queue drops packets under congestion. Cisco IOS, IOS XE and NX-OS are confirmed not affected — this is specific to IOS XR.

What to do

  • Check whether the management interface is up and has an IP assigned using show interfaces MgmtEth 0/RP0/CPU0/0; devices without this configuration are not exposed.
  • There is no workaround — Cisco has confirmed LPTS does not mitigate this, so upgrading is the only fix.
  • Upgrade to the first fixed release for your train: 24.2.21 (from 24.2), 25.1.2 (from 25.1), or 25.2.1 (from 25.2).
  • For 7.11 and earlier, 24.1, 24.3, and 24.4, Cisco is not issuing a fix on those trains — migrate to one of the fixed releases above.
  • Cisco has stated it will not release SMUs for this issue, so a full software upgrade is required rather than a point patch.
  • Watch for the PKT_INFRA-PQMON-6-QUEUE_DROP log signature referencing the ARP process as an indicator that a device is already experiencing this condition.
  • Consider restricting or monitoring traffic reaching management interfaces where feasible, given the lack of a Cisco-supplied workaround.

Fixed releases

Affected release First fixed release
24.2 24.2.21
25.1 25.1.2
25.2 25.2.1

For leadership 🧭

Executive summary. Any IOS XR router or switch with a live IP on its management Ethernet port can be pushed into unresponsiveness by an adjacent attacker flooding it with ARP traffic. There’s no workaround, so this needs to be scheduled for a software upgrade rather than mitigated in place.

Why it matters:

  • An unauthenticated attacker on the same segment as the management interface (MgmtEth 0/RP0/CPU0/0) can trigger a broadcast storm that overwhelms ARP processing, with no credentials or user interaction needed.
  • Cisco has confirmed LPTS provides no rate-limiting for traffic hitting management Ethernet interfaces, so there is no existing protection mechanism to fall back on while a fix is scheduled.
  • Impact escalates from degraded performance to total loss of management connectivity and full device unresponsiveness, which for a router or switch means losing remote control at the worst possible time.
  • Cisco will not issue SMUs for this issue, meaning affected devices need a full software upgrade rather than a quick patch, and several trains (7.11 and earlier, 24.1, 24.3, 24.4) have no fix at all and must migrate to a different train.

Now / Next / Later:

  • Now: Run show interfaces MgmtEth 0/RP0/CPU0/0 on IOS XR devices to identify which ones have the management interface up with an IP assigned, and check logs for the PKT_INFRA-PQMON-6-QUEUE_DROP signature indicating the condition is already occurring.
  • Next: Schedule an upgrade to the first fixed release for each affected train — 24.2.21, 25.1.2 or 25.2.1 — and plan migration off 7.11-and-earlier, 24.1, 24.3 and 24.4 since those trains receive no fix.
  • Later: Where feasible, restrict which hosts can reach management interfaces at the network level (dedicated management VLAN, ACLs upstream, or physical segregation), since IOS XR itself offers no built-in throttling for this traffic.

Source