CVE-2026-20182 Sumo Logic CSE · Sumo

Detect Cisco Catalyst SD-WAN Controller Authentication Bypass (CVE-2026-20182) in Sumo Logic CSE

Detects exploitation attempts of CVE-2026-20182, an authentication bypass vulnerability (CWE-287) in the Cisco Catalyst SD-WAN Controller. This KEV-listed vulnerability allows unauthenticated remote attackers to bypass authentication mechanisms and gain unauthorized access to the SD-WAN management plane. Successful exploitation can lead to full network fabric compromise, configuration tampering, and lateral movement across SD-WAN-connected sites.

MITRE ATT&CK

Tactic
Initial Access Privilege Escalation Defense Evasion Lateral Movement

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql 
_sourceCategory=cisco/sdwan OR _sourceCategory=network/firewall OR _sourceCategory=cisco/vmanage
| where _sourceCategory matches "cisco*" or _sourceCategory matches "*sdwan*" or _sourceCategory matches "*vmanage*"
| parse "*" as raw_msg nodrop
| parse field=raw_msg "src=* " as src_ip nodrop
| parse field=raw_msg "dst=* " as dst_ip nodrop
| parse field=raw_msg "dport=*" as dst_port nodrop
| parse field=raw_msg "status=*" as http_status nodrop
| parse field=raw_msg "uri=*" as uri nodrop
| where (
    (uri matches "/dataservice*" or uri matches "/api/*" or uri matches "/j_security_check*")
    or (raw_msg matches "*authentication bypass*" or raw_msg matches "*unauthorized*" or raw_msg matches "*auth failed*")
    or dst_port in ("443", "8443", "8080", "830", "8888")
  )
| where !(src_ip matches "10.*" or src_ip matches "172.16.*" or src_ip matches "172.17.*" or src_ip matches "192.168.*")
| timeslice 5m
| stats
    count as event_count,
    count_distinct(src_ip) as unique_sources,
    values(uri) as accessed_paths,
    values(http_status) as http_statuses
  by _timeslice, dst_ip
| where event_count > 10 or unique_sources > 3
| fields _timeslice, dst_ip, event_count, unique_sources, accessed_paths, http_statuses
| sort by event_count desc
critical severity medium confidence

Sumo Logic query detecting external authentication bypass attempts against Cisco Catalyst SD-WAN management endpoints by correlating event volume, URI patterns, and external source IPs.

Data Sources

Cisco SD-WAN syslogsCisco vManage audit logsNetwork perimeter firewall logs

Required Tables

_sourceCategory=cisco/sdwan_sourceCategory=cisco/vmanage_sourceCategory=network/firewall

False Positives & Tuning

  • Third-party SD-WAN management overlays or SASE platforms with external IP addresses
  • Legitimate API polling from cloud-hosted monitoring services
  • Authorized VPN or remote access solutions that egress with public IP addresses
  • Partner or contractor administrative access from non-RFC1918 source ranges

Other platforms for CVE-2026-20182

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Unauthenticated vManage API Endpoint Enumeration

    Expected signal: HTTP GET requests to vManage management port (8443) targeting /dataservice/* and /j_security_check endpoints from the test host IP, captured in vManage access logs and network firewall logs. Response codes of 200 or 401/403 depending on vulnerability state.

  2. Test 2Authentication Bypass Session Token Forge Attempt

    Expected signal: POST requests to /j_security_check and GET requests to /dataservice/* with anomalous Authorization headers or malformed JSESSIONID cookies visible in vManage access logs, web proxy logs, and network PCAP. HTTP response codes of 200, 302, 401, or 403 depending on patch state.

  3. Test 3Post-Exploitation SD-WAN Configuration Exfiltration Simulation

    Expected signal: Sequential GET requests to /dataservice/device, /dataservice/template/device, and /dataservice/system/device/controllers within a short time window, all using the same session cookie. Requests captured in vManage audit log as API access events and in network logs as HTTPS traffic to management port.

Last updated: 2026-06-19 Research depth: standard
References (4)

Response Playbook

Triage

  1. Identify the source IP(s) triggering the alert and determine if they belong to authorized management networks, known Cisco TAC ranges, or approved third-party administrators. Cross-reference against an approved source IP allowlist for SD-WAN management access.
  2. Inspect SD-WAN vManage audit logs for the time window of the alert. Look for session creation events that lack a corresponding valid credential authentication event, or sessions associated with usernames that do not exist in the identity provider.
  3. Check for configuration changes made to the SD-WAN fabric during or shortly after the detected authentication event. Any policy modification, route change, or template push from an unrecognized session should be treated as confirmed compromise.
  4. Correlate the suspicious source IP against threat intelligence feeds, recent CISA KEV alerts, and internal threat intel to determine if it is associated with known exploitation campaigns targeting Cisco SD-WAN infrastructure.
  5. Determine the scope of access: which vManage tenants, vSmart controllers, or vBond orchestrators were reachable from the suspicious session. Map the full SD-WAN topology potentially exposed.

Containment

  1. Immediately isolate the Cisco vManage controller from external network access by applying ACLs or firewall rules blocking inbound connections to management ports (443, 8443, 8080, 830) from all non-explicitly-approved source ranges. Coordinate with network operations to avoid disrupting legitimate SD-WAN control plane traffic.
  2. Revoke all active sessions on the vManage controller and force re-authentication for all administrators. Rotate all API keys, service account credentials, and any tokens that may have been accessible to the unauthorized session. If SSO integration is present, invalidate cached tokens at the identity provider level.
  3. Apply the Cisco-provided patch or workaround from the security advisory (cisco-sa-sdwan-rpa2-v69WY2SW) immediately. If patching is not immediately possible, implement the compensating controls specified in CISA Emergency Directive ED-26-03.

Evidence Collection

  1. Export and preserve the complete vManage audit log, system log, and access log for the affected timeframe. Capture these logs to an immutable storage location before any remediation actions that might rotate logs. Include at minimum the 48-hour window before and after the detection event.
  2. Capture a snapshot of the current SD-WAN policy configuration, routing tables, and template assignments. Diff this snapshot against the last known-good configuration backup to identify any unauthorized changes introduced during the compromised session.
  3. Collect NetFlow or PCAP data from the network segment hosting the vManage controller for the detection window. Preserve any HTTP/HTTPS request logs showing the specific URIs accessed, response codes, and session tokens used.

Escalation Criteria

  • !Escalate immediately to CISO and incident response leadership if any unauthorized configuration changes to SD-WAN policies, routing, or access controls are confirmed, as this indicates the attacker has achieved control plane access with potential to disrupt all SD-WAN-connected sites.
  • !Escalate to CISA per Emergency Directive ED-26-03 reporting requirements if your organization is a federal agency or critical infrastructure operator. Document the timeline, affected systems, and any indicators of compromise for mandatory reporting within the ED-26-03 deadline.
  • !Escalate to Cisco PSIRT and TAC if the compromise is confirmed, to obtain forensic assistance and determine if additional undisclosed vulnerabilities were leveraged in conjunction with CVE-2026-20182.

Investigation Guide

Related Techniques

[object Object][object Object][object Object][object Object]

Forensic Artifacts

  • >vManage audit log entries (audit_log.log) showing session creation without preceding authentication events, or sessions from unexpected source IPs
  • >HTTP access logs on vManage showing successful 200/302 responses to /dataservice or /j_security_check endpoints from external IPs without valid JWT or session cookie
  • >SD-WAN configuration change history in vManage (Administration > Audit Log) showing unauthorized policy or template modifications
  • >NetFlow records showing sustained inbound connections to vManage management ports from external, non-approved IP addresses
  • >vManage system logs (/var/log/nms/) showing authentication module errors, bypass attempts, or session anomalies contemporaneous with the exploitation window

Tuning Guidance

Start by establishing a comprehensive allowlist of legitimate source IPs for SD-WAN management access, including corporate VPN egress IPs, dedicated jump hosts, and approved Cisco TAC ranges. Suppress alerts from these sources to reduce false positives. Tune the event count thresholds (default: 5 events per 5-minute window) based on baseline vManage API polling rates in your environment — environments with heavy automation may require thresholds of 50+ before anomaly is meaningful. For environments where vManage is not internet-exposed, increase confidence to 'high' and lower thresholds significantly. Consider adding a geo-anomaly component: flag sessions from geographies that have never previously accessed the management plane. If your organization has deployed Cisco Umbrella or similar DNS security, correlate DNS queries for vManage hostnames against this detection for higher-fidelity alerting.

Hunting Queries

Threat hunt for anomalous session volume spikes and unusual source IP diversity on Cisco SD-WAN vManage over the past 7 days, which may indicate exploitation attempts or post-compromise reconnaissance even if individual events did not trigger real-time alerts.

Hunting — KQL
kql 
CommonSecurityLog
| where DeviceVendor has "Cisco" and DeviceProduct has_any ("SD-WAN", "vManage")
| where TimeGenerated > ago(7d)
| where Activity has_any ("session", "login", "auth", "access")
| extend Hour = bin(TimeGenerated, 1h)
| summarize
    SessionCount = count(),
    UniqueUsers = dcount(SourceUserName),
    UniqueIPs = dcount(SourceIP),
    IPList = make_set(SourceIP, 20)
  by Hour
| where SessionCount > percentile_tdigest(SessionCount, 95)
   or UniqueIPs > 10
| order by Hour desc
Hunting — SPL
spl 
index=cisco sourcetype="cisco:vmanage" earliest=-7d
("session" OR "login" OR "auth" OR "access")
| bucket _time span=1h
| stats
    count as session_count,
    dc(src_ip) as unique_ips,
    dc(user) as unique_users,
    values(src_ip) as ip_list
  by _time
| eventstats perc95(session_count) as p95_sessions
| where session_count > p95_sessions OR unique_ips > 10
| sort -session_count

Retrospective hunt over 30 days identifying external source IPs with unusually high success rates on authenticated SD-WAN API endpoints, which may indicate prior exploitation attempts before the CVE was publicly disclosed or patched.

Hunting — KQL
kql 
W3CIISLog
| where csUriStem startswith "/dataservice"
| where scStatus in (200, 302, 401, 403)
| where TimeGenerated > ago(30d)
| summarize
    Requests = count(),
    StatusCodes = make_set(scStatus),
    SuccessRate = countif(scStatus in (200, 302)) * 100.0 / count()
  by cIP, bin(TimeGenerated, 1h)
| where SuccessRate > 80 and Requests > 20
| where not (cIP startswith "10." or cIP startswith "172.16." or cIP startswith "192.168.")
| order by Requests desc
Hunting — SPL
spl 
index=web sourcetype=access_combined uri_path="/dataservice*" earliest=-30d
| stats
    count as request_count,
    count(eval(status IN (200, 302))) as success_count,
    eval(success_rate=round(success_count/request_count*100,1))
  by src_ip, date_hour
| where success_rate > 80 AND request_count > 20
| where NOT (match(src_ip, "^10\..*") OR match(src_ip, "^172\.1[6-9]\..*") OR match(src_ip, "^192\.168\..*"))
| sort -request_count

Atomic Red Team Tests

Test 1 Unauthenticated vManage API Endpoint Enumeration
linux

Simulates reconnaissance phase of CVE-2026-20182 exploitation by probing Cisco vManage REST API endpoints without authentication to identify accessible resources, mimicking the initial access pattern of an attacker leveraging the authentication bypass.

Command

bash 
TARGET_HOST="192.168.100.10"; TARGET_PORT="8443"; for endpoint in "/dataservice/device" "/dataservice/template/device" "/dataservice/system/device/controllers" "/j_security_check" "/dataservice/statistics/interface"; do echo "[*] Probing: https://${TARGET_HOST}:${TARGET_PORT}${endpoint}"; curl -sk -o /dev/null -w "%{http_code} %{url_effective}\n" -X GET "https://${TARGET_HOST}:${TARGET_PORT}${endpoint}" --max-time 5; done

Cleanup

bash 
No persistent changes made; all requests are read-only HTTP probes. Ensure lab vManage audit logs are reviewed and cleared if needed for subsequent test isolation.

Expected Telemetry

HTTP GET requests to vManage management port (8443) targeting /dataservice/* and /j_security_check endpoints from the test host IP, captured in vManage access logs and network firewall logs. Response codes of 200 or 401/403 depending on vulnerability state.

Expected Detection

Alert should fire on the KQL/SPL queries detecting external probing of SD-WAN management endpoints with >3 requests within the 5-minute window. Chronicle YARA-L rule should trigger on network_http events matching the URI patterns.

Test 2 Authentication Bypass Session Token Forge Attempt
linux

Simulates the core exploitation mechanic of CVE-2026-20182 by sending crafted HTTP requests with manipulated authentication headers to vManage, attempting to bypass JWT validation. Lab environment only.

Command

bash 
TARGET="https://192.168.100.10:8443"; echo "[*] Testing auth bypass with malformed token"; curl -sk -X POST "${TARGET}/j_security_check" -H 'Content-Type: application/x-www-form-urlencoded' -d 'j_username=bypass&j_password=bypass' -D - | grep -E '(HTTP|Set-Cookie|Location)'; echo "[*] Testing with null bearer token"; curl -sk -X GET "${TARGET}/dataservice/device" -H 'Authorization: Bearer ' -H 'Content-Type: application/json' -D - | head -50; echo "[*] Testing with empty session cookie"; curl -sk -X GET "${TARGET}/dataservice/template/device" -H 'Cookie: JSESSIONID=' -D - | head -50

Cleanup

bash 
No filesystem changes. Review and purge vManage session logs for any test sessions that may have been created. Rotate any test credentials used.

Expected Telemetry

POST requests to /j_security_check and GET requests to /dataservice/* with anomalous Authorization headers or malformed JSESSIONID cookies visible in vManage access logs, web proxy logs, and network PCAP. HTTP response codes of 200, 302, 401, or 403 depending on patch state.

Expected Detection

KQL query should surface the POST to /j_security_check combined with subsequent successful dataservice access. EQL sequence rule should trigger on the three-event chain: connection to management port, successful HTTP response on authenticated endpoint, session event.

Test 3 Post-Exploitation SD-WAN Configuration Exfiltration Simulation
linux

Simulates post-exploitation data collection by an attacker who has successfully bypassed authentication on vManage, harvesting network topology and routing configuration via the vManage REST API as would occur after exploiting CVE-2026-20182.

Command

bash 
TARGET="https://192.168.100.10:8443"; SESSION_COOKIE="JSESSIONID=TEST_SESSION_TOKEN"; echo "[*] Enumerating SD-WAN device inventory"; curl -sk -X GET "${TARGET}/dataservice/device" -H "Cookie: ${SESSION_COOKIE}" -H 'Content-Type: application/json' | python3 -m json.tool 2>/dev/null | head -100; echo "[*] Dumping device templates"; curl -sk -X GET "${TARGET}/dataservice/template/device" -H "Cookie: ${SESSION_COOKIE}" -H 'Content-Type: application/json' | python3 -m json.tool 2>/dev/null | head -100; echo "[*] Collecting vSmart controller list"; curl -sk -X GET "${TARGET}/dataservice/system/device/controllers" -H "Cookie: ${SESSION_COOKIE}" -H 'Content-Type: application/json' | python3 -m json.tool 2>/dev/null | head -50

Cleanup

bash 
No changes made to target system. All operations are read-only GET requests. Ensure test session token is invalidated in vManage after test completion.

Expected Telemetry

Sequential GET requests to /dataservice/device, /dataservice/template/device, and /dataservice/system/device/controllers within a short time window, all using the same session cookie. Requests captured in vManage audit log as API access events and in network logs as HTTPS traffic to management port.

Expected Detection

SPL query should detect the burst of API endpoint access from a single source IP within the 5-minute bucket threshold. Sumo Logic query should flag the volume of /dataservice/* requests. Threat hunt queries should surface this host as having an anomalously high success rate on authenticated API endpoints.

Related Detections

Tactic Hubs

TA0001Initial AccessTA0004Privilege EscalationTA0005Defense EvasionTA0008Lateral Movement

Related Techniques

T1190Exploit Public-Facing ApplicationT1078Valid AccountsT1556Modify Authentication ProcessT1021.007Cloud Services

Same Tactic: Initial Access

Popular Detections