CVE-2025-20137: Cisco IOS ACL Bypass Vulnerability

CVE-2025-20137 Overview

CVE-2025-20137 is an access control weakness in the access control list (ACL) programming of Cisco IOS Software running on Cisco Catalyst 1000 and Catalyst 2960L Switches. An unauthenticated, adjacent attacker can bypass a configured IPv4 ACL by sending traffic through an affected interface. The flaw is triggered when an administrator configures both an IPv4 ACL and IP Source Guard (a dynamic ACL feature) on the same interface, which Cisco has now documented as an unsupported configuration. Cisco does not plan to add support for combining both features on the same interface for these switch families [CWE-284].

Critical Impact
Attackers with adjacent network access can bypass configured IPv4 ACLs, allowing unauthorized Layer 3 traffic to traverse switch interfaces and reach otherwise restricted network segments.

Affected Products

Cisco IOS Software (multiple 15.2(x)E trains running on the platforms below)
Cisco Catalyst 1000 Series Switches (all C1000 and C1000FE SKUs, 8- to 48-port variants)
Cisco Catalyst 2960L Series Switches (all 2960L SKUs, 8- to 48-port variants)

Discovery Timeline

2025-05-07 - CVE-2025-20137 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-20137

Vulnerability Analysis

The vulnerability is an improper access control issue in how Cisco IOS programs ACL entries into hardware when two ACL-producing features share the same interface. Cisco Catalyst 1000 and 2960L switches allow administrators to configure a static IPv4 ACL alongside IP Source Guard on the same physical interface. IP Source Guard installs a dynamic ACL derived from DHCP snooping or static bindings, and the two ACL sources interact incorrectly in the switch data plane.

When both features are active on the interface, the resulting programmed policy does not enforce the administrator-defined IPv4 ACL as intended. Traffic that should be dropped by the static ACL is instead forwarded. Because these platforms process ACLs in hardware, the misprogramming persists silently and is not surfaced through configuration warnings.

Root Cause

The root cause is a configuration combination that Cisco IOS accepts but does not correctly reconcile at the hardware ACL layer. The device does not block the administrator from applying both an IPv4 ACL and IP Source Guard on the same interface, even though this combination is unsupported. There are no plans to add enforcement logic for these switch families, so the fix is documentation-based rather than a software patch.

Attack Vector

Exploitation requires an attacker on the adjacent network (Layer 2 reachable to the affected switch interface). The attacker sends IPv4 traffic through the misconfigured port that would normally be denied by the configured ACL. Because the effective policy is not enforced as expected, the traffic transits the switch and reaches destinations the ACL was meant to protect. No authentication or user interaction is required, and impact is limited to integrity of traffic filtering rather than confidentiality or availability of the switch itself.

No verified proof-of-concept code has been published for this issue. Refer to the Cisco Security Advisory for technical details.

Detection Methods for CVE-2025-20137

Indicators of Compromise

Traffic observed on downstream network segments that should be blocked by a configured IPv4 ACL on a Catalyst 1000 or 2960L interface.
Interfaces where both ip access-group and ip verify source (IP Source Guard) are applied simultaneously.
Flow records showing source or destination addresses reaching services that the ACL policy explicitly denies.

Detection Strategies

Audit running configurations of all Catalyst 1000 and 2960L switches for interfaces that combine an IPv4 ACL with IP Source Guard.
Compare ACL hit counters against expected deny rates; unusually low deny counts on affected interfaces may indicate bypass.
Perform active validation by sending test traffic that the ACL should deny and confirming it is dropped upstream and downstream of the switch.

Monitoring Recommendations

Forward switch configuration snapshots and NetFlow or sFlow telemetry to a centralized analytics platform for policy drift detection.
Alert on configuration changes that add ip verify source to interfaces already carrying an ip access-group statement.
Track syslog events for ACL, DHCP snooping, and IP Source Guard subsystems to correlate policy changes with traffic anomalies.

How to Mitigate CVE-2025-20137

Immediate Actions Required

Inventory all Cisco Catalyst 1000 and 2960L switches and identify interfaces where an IPv4 ACL and IP Source Guard are both configured.
Remove one of the two features from any interface where both are present, based on which control is required by policy.
Validate the resulting filtering behavior with traffic tests before returning affected ports to production.

Patch Information

Cisco has stated there are no plans to implement support for configuring both an IPv4 ACL and IP Source Guard on the same interface on Cisco Catalyst 1000 or Catalyst 2960L Switches. Cisco has updated its documentation to reflect that this is an unsupported configuration. Administrators should treat the Cisco Security Advisory (cisco-sa-ipsgacl-pg6qfZk) as the authoritative remediation guidance.

Workarounds

Enforce IPv4 filtering with a static ACL only, and rely on DHCP snooping without IP Source Guard for binding hygiene.
Alternatively, use IP Source Guard alone for source validation and move Layer 3 filtering to an upstream router or Layer 3 switch.
Standardize interface templates so that operational teams cannot inadvertently combine the two features during future changes.

bash

# Configuration example: remove IP Source Guard from an interface that requires an IPv4 ACL
configure terminal
interface GigabitEthernet1/0/1
 no ip verify source
 ip access-group PROTECT_SEGMENT in
end
write memory

# Alternative: keep IP Source Guard and remove the interface ACL,
# then apply filtering upstream on a Layer 3 device
configure terminal
interface GigabitEthernet1/0/1
 no ip access-group PROTECT_SEGMENT in
 ip verify source
end
write memory