Cisco IOS XE SD-WAN Software Packet Filtering Bypass Vulnerability

🚨SEVERITY: MEDIUM — CVSS 5.3Security Advisory

TL;DR 📌

  • A vulnerability in the packet filtering features of Cisco IOS XE SD-WAN Software could allow an unauthenticated, remote attacker to bypass Layer 3 and Layer 4 traffic filters. This vulnerability is due to improper traffic filtering conditions on an affected device. An attacker could exploit this vulnerability by sending a crafted packet to the affected…
  • Highest CVSS: 5.3 (Medium).
  • Check the advisory for fixed releases — remediation detail is in the vendor link below.
  • CVEs: CVE-2025-20221.

What it is

CVE-2025-20221 sits in the packet filtering feature of Cisco IOS XE SD-WAN Software, specifically on cEdge routers running in Controller mode with SNMP enabled on an SD-WAN tunnel interface. The flaw is caused by improper traffic filtering conditions on the device.

An unauthenticated, remote attacker can send a crafted packet to the affected device over the network. Because the Layer 3 and Layer 4 traffic filters do not evaluate the packet correctly, the attacker can bypass those filters and inject a crafted packet into the network behind them.

The advisory notes this only affects cEdge routers where SNMP (SNMPv1, SNMPv2c, or SNMPv3) is enabled on an SD-WAN tunnel interface — if SNMP is not enabled, the device is not exposed. Devices not in Controller mode, or without SD-WAN enabled, are also not affected. Cisco has confirmed that IOS Software, Meraki, and NX-OS Software are not affected.

On the version side, universal Cisco IOS XE Software 17.2.1r and later running in Controller mode is affected, as is that SD-WAN feature set was only introduced from 17.2.1r onward. Separately, standalone Cisco IOS XE SD-WAN Software releases 16.9.1 through 16.9.4, 16.10.1 through 16.10.5, 16.11.1a, and 16.12.2r through 16.12.4 are affected. Releases earlier than 17.2.1r that lack the SD-WAN feature entirely are not affected.

Cisco PSIRT states that proof-of-concept exploit code is available for this vulnerability, but it is not aware of any malicious use.

What to do

  • Check whether affected devices are running in Controller mode with SNMP enabled on an SD-WAN tunnel interface: use show running-config | include snmp-server community for SNMPv1/v2c, or show running-config | include snmp-server group plus show snmp user for SNMPv3. If neither returns output, the device is not exposed via this path.
  • If exposed, apply one of Cisco’s two workarounds via the SD-WAN Manager interface until you can upgrade: configure an extended ACL to control ingress/egress traffic on the cEdge, or push a device access policy that blocks unsolicited SNMP traffic (ensure SNMPv3 authorisation is required before any response is sent).
  • Use the Cisco Software Checker against your running release to identify the specific fixed release for your train; the advisory does not list fixed version numbers directly in the text provided, so run your release through the tool to get the “First Fixed” and “Combined First Fixed” output.
  • Given PoC code is public, treat this as a priority to remediate even though Cisco has not observed exploitation in the wild — don’t rely on the workaround as a long-term fix; plan the upgrade to a fixed release.
  • If you’re running IOS XE Software earlier than 17.2.1r, or IOS Software, Meraki, or NX-OS, no action is needed for this specific CVE.

For leadership 🧭

Executive summary. Cisco cEdge routers in Controller mode with SNMP switched on for an SD-WAN tunnel interface can have their Layer 3/4 traffic filters bypassed by an unauthenticated remote attacker sending a single crafted packet. Proof-of-concept code is public, so affected estates should confirm exposure and apply the workaround this week while a fixed release is scheduled.

Why it matters:

  • Bypasses the Layer 3/4 packet filters on cEdge routers, meaning ACL-based network segmentation on affected SD-WAN tunnels can no longer be trusted to block or admit traffic as configured.
  • No authentication is required — a remote attacker only needs to reach the tunnel interface and send one crafted packet to inject traffic past the filter.
  • Exposure is specific: only cEdge devices in Controller mode with SNMP (v1, v2c, or v3) enabled on an SD-WAN tunnel interface are affected; devices without SNMP on that interface, or not in Controller mode, are untouched.
  • Proof-of-concept exploit code is already available, increasing the chance of opportunistic use even though Cisco has not observed exploitation to date.

Now / Next / Later:

  • Now: Run show running-config | include snmp-server community and, for SNMPv3, show running-config | include snmp-server group plus show snmp user on every cEdge router in Controller mode to identify which devices have SNMP enabled on an SD-WAN tunnel interface and are therefore exposed.
  • Next: On any exposed cEdge device, push either an extended ACL restricting ingress/egress traffic or a device access policy blocking unsolicited SNMP traffic via SD-WAN Manager, then run the affected release through the Cisco Software Checker to identify the correct fixed version for the upgrade.
  • Later: Schedule upgrades to the fixed IOS XE SD-WAN release identified by the Software Checker for all Controller-mode cEdge devices, and review whether SNMP needs to remain enabled on SD-WAN tunnel interfaces at all, restricting it where it is not operationally required.

Source