CVE-2024-20373: Cisco IOS XE SD-WAN Auth Bypass Vulnerability

CVE-2024-20373 Overview

Cisco disclosed CVE-2024-20373, an access control weakness in the Simple Network Management Protocol (SNMP) IPv4 access control list (ACL) implementation of Cisco IOS Software and Cisco IOS XE Software. The flaw allows an unauthenticated, remote attacker to perform SNMP polling of an affected device even when administrators intend SNMP traffic to be denied. The issue arises because Cisco IOS and IOS XE do not support extended IPv4 ACLs for SNMP, yet permit administrators to attach extended named IPv4 ACLs to the SNMP server configuration without emitting a warning. The vulnerability is tracked under [CWE-284: Improper Access Control].

Critical Impact
An attacker with a valid SNMPv2c community string or SNMPv3 credentials can query devices that appear to be protected by an ACL, enabling unauthorized reconnaissance and configuration disclosure.

Affected Products

Cisco IOS Software with extended named IPv4 ACLs applied to SNMP server configuration
Cisco IOS XE Software with extended named IPv4 ACLs applied to SNMP server configuration
Cisco IOS XE SD-WAN releases 16.9.x through 16.12.x (per NVD CPE data)

Discovery Timeline

2024-11-15 - CVE-2024-20373 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-20373

Vulnerability Analysis

The vulnerability resides in how Cisco IOS and IOS XE parse and enforce ACLs attached to the SNMP listening process. Standard numbered and named IPv4 ACLs are supported for SNMP, but extended IPv4 ACLs are not. When an administrator attaches an extended named IPv4 ACL to the SNMP server configuration, the CLI accepts the command without warning. At runtime, the SNMP process fails to apply the unsupported ACL, and the result is an SNMP listener with no source-address restriction. An attacker can therefore query the device from any reachable network location, provided they possess a valid SNMPv2c community string or SNMPv3 credentials. The attacker cannot modify the ACL, and IPv6 ACL configurations for SNMP are not affected.

Root Cause

The root cause is missing input validation and missing enforcement in the SNMP ACL binding logic. The configuration parser does not reject or warn against extended IPv4 ACL attachments, and the SNMP listener silently omits ACL enforcement when the referenced ACL type is unsupported. This is a classic fail-open condition mapped to [CWE-284].

Attack Vector

Exploitation requires network reachability to UDP/161 on the affected device and knowledge of a valid SNMP community string or SNMPv3 user credentials. The attacker issues standard SNMP GET, GETNEXT, or GETBULK requests. Because no ACL enforcement occurs, the requests are processed regardless of the source IP address that the administrator intended to block. Successful polling can reveal interface configuration, routing tables, ARP entries, running processes, and other information that supports lateral movement or infrastructure mapping.

No verified public exploit code is available. See the Cisco Security Advisory: SNMP Vulnerability for authoritative technical detail.

Detection Methods for CVE-2024-20373

Indicators of Compromise

SNMP GET or GETBULK requests to affected devices originating from source addresses that the intended ACL should have blocked.
Unexpected SNMP traffic observed on UDP/161 in NetFlow, IPFIX, or firewall logs from external or untrusted subnets.
Authentication successes in SNMPv3 audit logs from unfamiliar principals or hosts.

Detection Strategies

Audit device configurations for snmp-server community or snmp-server group statements that reference extended named IPv4 ACLs, using show running-config | include snmp-server.
Compare the ACL type referenced by SNMP against the ACL definition to confirm it is a standard ACL and enforcement is actually taking place.
Correlate SNMP flow records with the intended ACL policy to identify traffic that should have been denied.

Monitoring Recommendations

Forward device syslog and SNMP engine logs to a centralized platform such as Singularity Data Lake for retention and correlation.
Alert on SNMP polls from source prefixes outside the approved management network.
Baseline normal SNMP polling volumes and generate anomalies on unexpected spikes or new source addresses.

How to Mitigate CVE-2024-20373

Immediate Actions Required

Inventory all Cisco IOS and IOS XE devices and identify SNMP server configurations that reference extended named IPv4 ACLs.
Replace unsupported extended ACLs with standard numbered or standard named IPv4 ACLs that Cisco IOS supports for SNMP.
Rotate SNMPv2c community strings and SNMPv3 credentials if the device may have been polled from untrusted sources.
Apply the fixed Cisco IOS or IOS XE software release identified in the vendor advisory.

Patch Information

Cisco has released fixed software. Refer to the Cisco Security Advisory: SNMP Vulnerability for the specific fixed releases that apply to each affected train, including Cisco IOS XE SD-WAN 16.9 through 16.12 branches.

Workarounds

Reconfigure SNMP to use a standard IPv4 ACL rather than an extended IPv4 ACL to ensure enforcement is applied.
Restrict SNMP traffic upstream using infrastructure ACLs, control plane policing (CoPP), or firewall rules that limit UDP/161 to the approved management subnets.
Prefer SNMPv3 with authentication and privacy over SNMPv2c to reduce the value of any leaked community strings.

bash

# Replace an extended named ACL with a supported standard ACL for SNMP
ip access-list standard SNMP-MGMT
 permit 10.10.0.0 0.0.255.255
 deny   any log
!
snmp-server community <community> RO SNMP-MGMT
!
# Verify enforcement
show running-config | include snmp-server
show ip access-lists SNMP-MGMT