Cisco-Unified-Communications-Manager-Server-Side-Forgery-Request-Vulnerability-CVE-2026-20230

Analyzes CVE-2026-20230 SSRF to arbitrary file write and RCE in Cisco Unified Communications Manager, providing PoC derivation, detection logic, and defensive guidance.

Although the CVSS score indicates High severity, Cisco marked the Security Impact Rating as Critical. The reason is that successful exploitation can lead to writing files to the underlying OS and potentially escalate to root privileges.

It is important to note that a key prerequisite for this vulnerability is that the WebDialer service must be enabled. WebDialer is disabled by default, so simply seeing a CUCM asset does not directly indicate the vulnerability is exploitable. Proper risk assessment requires confirming the product version, patch status, WebDialer service status, and whether related interfaces are accessible.

2. Why Can't You Just Check Whether an Interface Returns 200?

This vulnerability is not an ordinary Web vulnerability where "accessing a fixed URL and returning 200 means it exists." Its exploitation chain involves at least three layers:

1. Externally accessible WebDialer or cmplatform-related interfaces.
2. Internal access logic that can be affected by SSRF.
3. File write or service deployment behavior that can be further triggered by internal requests.

Therefore, simply accessing an interface and getting HTTP 200, 302, 401, 404, or 500 cannot directly prove the existence or absence of the vulnerability.

For example, the fact that the WebDialer WSDL interface is accessible only indicates that the target exposes WebDialer-related functionality; it does not prove that subsequent SSRF will necessarily bypass filtering. Similarly, the fact that the installClusterStatusExecute interface is accessible only indicates that the entry point exists, but does not independently prove that arbitrary file writing has been achieved. Conversely, if a step returns an anomaly, it could be caused by the target version, patch, hostname resolution, path permissions, proxy device, or service status, and does not necessarily mean the entire exploitation chain does not exist.

A more reliable judgment should adopt a multi-stage evidence combination:

1. Confirm the target is Cisco Unified CM / Unified CM SME.
2. Confirm the WebDialer service is enabled.
3. Confirm the ability to obtain the target's real hostname or internal service identifier.
4. Confirm the SSRF entry point is reachable and there are signs of the server initiating internal requests.
5. In an authorized test environment, confirm whether controlled file write evidence can be generated.
6. Combine server logs, file system changes, Web container logs, and alert data to determine if actual exploitation occurred.

Only when "WebDialer enabled + affected version + SSRF behavior confirmed + controlled file write confirmed" all appear together should it be judged as high-confidence exploitable.

3. PoC Construction Approach

The core of the currently public exploitation chain is not simple SSRF, but a combined use of SSRF with Axis/Java Web service mechanisms, log writing, or deployment descriptor processing logic.

The overall approach can be summarized as:

From the chain design perspective, hostname is a key point. Some filtering logic may block common local addresses such as 127.0.0.1 and localhost, but the target's real hostname might be allowed into subsequent request processing. Therefore, the PoC first extracts the real hostname from the WebDialer WSDL information, then uses it as the internal access prefix in the SSRF chain.

The second key point is the Axis service-related logic. The PoC does not directly upload files to the Web directory; instead, through the internal service processing chain, it causes server-side components to write attacker-controlled content to specific paths. This process is essentially a combination of "server-side internal request + component configuration/log writing behavior + path traversal/path control."

The third key point is the two-stage writing. The first stage is usually used to establish a more stable file write entry point, and the second stage writes the command execution script to a Web-accessible directory. The reason is that directly writing a complete command execution logic in one step through SSRF may be affected by encoding, length, XML structure, path permissions, and server-side parsing behavior. The two-stage approach makes it easier to break down complex payloads.

This article does not provide complete exploitation payloads or WebShell content. For protection and verification, it is only necessary to understand the following core characteristics:

4. Hostname Retrieval Logic

The PoC first needs to obtain the target's real hostname, not just its IP address or external domain name.

The reason is that SSRF filtering logic may not only check the final connection target but also validate the hostname field, URL string, local address keywords, etc. Common local addresses like 127.0.0.1 and localhost may be blocked, while the device's real hostname may be considered a legitimate node name in some scenarios.

Interfaces that can assist in this determination are usually related to WebDialer WSDL information. After accessing such WSDL, the response may contain service addresses, location fields, or other parsable host identifiers. The PoC extracts the hostname from the URL in the response text and uses it as the internal access target for the next SSRF stage.

The judgment criteria for this stage should be:

1. Whether the WSDL interface is accessible.
2. Whether the response content matches WebDialer / Axis service characteristics.
3. Whether a real hostname can be parsed from the response.
4. Whether the parsed hostname differs from the external access IP or domain.
5. Whether that hostname can be accepted by the subsequent SSRF entry point.

If hostname parsing fails, the PoC may fall back to the target IP, but this significantly lowers the success rate. In real environments, common reasons for hostname parsing failure include WebDialer not being enabled, the interface being restricted by access controls, the response being rewritten by a reverse proxy, or incomplete certificate or service configuration.

5. SSRF Trigger Stage

The SSRF trigger point is located in the logic for querying cmplatform installation status. This functionality is originally used to query the installation status of cluster nodes. The server assembles an internal request based on the node identifier or hostname submitted by the user.

The core problem is that the attacker-controlled hostname parameter is not strictly restricted to legitimate node names or trusted hosts, allowing this parameter to be crafted into more complex internal access paths. The server then initiates requests to internal interfaces on behalf of the attacker.

At this stage, the key is not "being able to access an external URL," but "being able to make the CUCM device itself access its internally reachable WebDialer / Axis management interfaces." Therefore, the value of SSRF comes from two aspects:

1. Bypassing external network access restrictions to reach service paths that can only be accessed by the local machine or internal components.
2. Using the trust boundary of internal services to convert ordinary HTTP parameters into internal component operations.

During authorized verification, SSRF success cannot be judged solely by the HTTP status code. More reliable evidence includes:

1. Server-side logs showing access records to internal paths.
2. The request response content containing internal interface characteristics.
3. Subsequent WebDialer services pages showing new or abnormal service traces.
4. Anomalous files created by the server process appearing in the file system.
5. Security devices recording hostname parameters containing abnormal paths, encoded content, or internal service paths.

6. Axis Service Write and Arbitrary File Write Approach

In the public chain, SSRF is further used to access Axis-related service interfaces and attempt to write service deployment descriptor content. By constructing special XML/WSDD structures, the attacker causes the server-side components to write controlled content to specified paths during processing.

The essence of this stage is not traditional file upload, but abusing the processing logic of server-side components:

From a security analysis perspective, here are several key points:

1. The target path for writing typically requires traversal to a Web container accessible directory.
2. The written content must conform to the processing format of the server-side component; otherwise, it may only produce invalid files.
3. The owner and permissions of the written file depend on the Tomcat / CUCM service process.
4. If the write location is Web-accessible, file writing may further convert into script execution.
5. Even if the write location is not executable, it may still cause configuration pollution, persistence, or subsequent privilege escalation conditions.

Therefore, the high-risk point of CVE-2026-20230 is not just SSRF, but that SSRF can cross trust boundaries, enter internal management/service deployment chains, and ultimately trigger controlled file writing.

7. Two-Stage WebShell Write Logic

PoC designs typically adopt a two-stage write approach rather than completing command execution in one step.

The first stage is used to create a simple file write capability. The goal of this stage is to allow the attacker to write content to a specified location on the server through a Web-accessible path.

The second stage then uses the write capability from the first stage to write the command execution script to a Web-accessible directory. Subsequently, the attacker can trigger system command execution via HTTP parameters.

The advantages of the two-stage design are:

1. Reduces the payload complexity of a single SSRF request.
2. Avoids payload corruption caused by XML, URL encoding, special character escaping, etc.
3. Separates "deploying a service" from "writing the final execution file," making debugging easier.
4. Easier to adjust the landing location on different target paths.
5. Decouples the subsequent command execution stage from the SSRF stage.

However, from a defense perspective, the two-stage write also creates clearer detection points:

1. The first anomalous request typically attempts to create a new service or write an intermediate JSP.
2. The second anomalous request typically accesses the intermediate JSP and carries parameters such as file name and file content.
3. The third stage accesses the final command execution JSP and carries authentication tokens or command parameters.
4. Web access logs will show consecutive accesses to paths like WebDialer, services, axis2-web, platform-services within a short time.
5. The file system may show anomalous JSP files, anomalous service names, anomalous log files, or new Web resources.

8. Complete PoC Execution Flow

The current PoC flow can be summarized as:

1. Parse the target address.
2. Access the WebDialer WSDL, attempt to extract the real hostname.
3. Construct SSRF requests targeting internal WebDialer / Axis management paths.
4. Write Axis service-related content through internal requests.
5. Access the services page to check if the anomalous service has been deployed.
6. Call the new service to write the first-stage file write script.
7. Access the first-stage script to write the second-stage command execution script.
8. Access the second-stage script to execute a test command.
9. Determine exploitation success based on HTTP responses, file landing results, and command output.

From the exploitation success rate perspective, the most critical failure points usually concentrate on:

1. WebDialer not enabled.
2. Hostname parsing failed or filtered.
3. SSRF requests did not actually enter internal services.
4. Axis service deployment failed.
5. Path traversal landing location does not match the target version.
6. Web directory not writable or scripts not executed.
7. Target already patched or using Cisco's temporary fix package.
8. Proxies, WAF, EDR, or file integrity monitoring blocking intermediate stages.

Therefore, this PoC has high exploitability on specific affected versions with matching default paths, but it is not a stable one-size-fits-all for all CUCM assets.

9. Success Judgment Logic

Success judgment for CVE-2026-20230 cannot simply be based on whether the script completes. A more reasonable judgment should be divided into four tiers.

Tier 1: Target Suspected Exposure

Conditions:

This only indicates the target has an associated attack surface; it does not prove the vulnerability is exploitable.

Tier 2: Vulnerability Suspected

Conditions:

In this case, further verification should be performed with server logs or authorized test environments.

Tier 3: File Write Confirmed

Conditions:

At this tier, it can be confirmed that the exploitation chain has broken through the ordinary SSRF stage and entered the arbitrary file write risk.

Tier 4: RCE Confirmed

Conditions:

Only this tier confirms remote command execution. Successful file write does not necessarily equal successful RCE, but in high-privilege service environments like CUCM, file write alone is sufficient to pose a serious risk.

10. Usage Examples

This article does not provide exploit execution examples that can be directly used for attacks.

In authorized environments, it is recommended to use "read-only checks" or "non-destructive verification" methods, for example:

Recommended checks include:

1. Whether the target is Cisco Unified CM / Unified CM SME.
2. Whether the WebDialer service is enabled.
3. Whether the WSDL is accessible.
4. Whether the services page is exposed.
5. Whether the target version is lower than the fixed version.
6. Whether there are traces of anomalous new JSP files, anomalous Axis services, or anomalous log writes.

It is not recommended to perform full file write or command execution verification on production systems. Even for authorized tests, priority should be given to isolated test environments, snapshot environments, or the verification process recommended by the vendor.

11. Security Boundaries in PoC Design

The security boundaries of such PoC must be clearly defined.

First, command execution should not be the default. The command execution stage is a high-risk verification that can easily cause system state changes, log contamination, service anomalies, or responses from security devices.

Second, WebShell should not be written by default. Even if a test file is written, it may be flagged by EDR, WebShell detection, file integrity monitoring, or compliance audit systems as a real intrusion.

Third, batch scanning against public network targets should not be performed. This vulnerability requires no authentication, and targets are mostly enterprise communication infrastructure. Unauthorized scanning and exploitation carry extremely high risk.

Fourth, check mode should be separated from exploitation mode. It is recommended to split the PoC into two scripts: one only for asset identification and service status judgment, and the other for file write verification only in local test environments or explicitly authorized environments.

Fifth, the target scope should be restricted. The PoC can include protection mechanisms such as local addresses, private network segments, whitelisted domains, authorization confirmation parameters, etc., to avoid accidentally affecting third-party systems.

Sixth, the RCE stage should be disabled by default. Even if research code is retained, it should require the user to explicitly pass an authorization confirmation parameter before allowing file write or command execution verification.

12. Insights for Protection Rule Design

From a traffic detection perspective, it is not sufficient to simply match a fixed file name, service name, or JSP name. The service names, file names, and paths in public PoCs can be modified, making single-string rules prone to missing detections.

A more reasonable detection approach is to extract features based on attack chain stages.

Category 1: Information Gathering Stage

Focus on:

If an external client accesses the WSDL and then the cmplatform installation status interface within a short time, the risk level should be raised.

Category 2: SSRF Trigger Stage

Focus on:

The key at this stage is that the hostname parameter no longer looks like a normal hostname but exhibits path-like, URL-like, encoded, or XML-like characteristics.

Category 3: Axis / WSDD Injection Stage

Focus on:

When these fields appear together, there should be high suspicion that the attacker is attempting to write controlled content via Axis service deployment descriptors.

Category 4: File Write Stage

Focus on:

If the attack traffic contains extensive ../, URL-encoded path traversal, JSP extensions, and Tomcat WebApp paths, it should be judged as high-risk.

Category 5: Command Execution Stage

Focus on:

From a rule design perspective, stage-based detection is recommended:

1. WebDialer information gathering: Low or medium severity alert.
2. cmplatform SSRF with anomalous hostname: High severity alert.
3. Axis/WSDD/LogHandler combined characteristics: Critical alert.
4. JSP file write or command execution parameters: Critical alert.
5. Multi-stage correlation hit: Directly upgrade to intrusion event.

13. Investigation and Forensics Recommendations

During emergency investigation, it is recommended to focus on the following locations and phenomena:

1. Whether the WebDialer access log contains anomalous WSDL and services enumeration.
2. Whether the cmplatform access log contains anomalous installClusterStatusExecute requests.
3. Whether the hostname parameter contains URL encoding, path traversal, Axis, WSDD, LogHandler, etc.
4. Whether anomalous JSP files appear in the Web directory.
5. Whether anomalous service names appear on the Axis services page or configuration.
6. Whether Tomcat logs, platform service logs contain anomalous deployment descriptors, XML parsing errors, or path write records.
7. Whether test files or unknown files appear in /tmp, WebApp directories, log directories.
8. Whether there are multi-stage consecutive accesses from the same source IP within a short time.
9. Whether there are traces of anomalous system command execution, process creation records, or shell-related behavior.
10. Whether there are root-privilege-related anomalous files, scheduled tasks, startup items, or persistence traces.

If exploitation is suspected, priority should be given to isolating management plane access, retaining logs and file system evidence, and then performing patch upgrades, WebShell cleanup, anomalous service cleanup, and account/credential rotation.

14. Remediation and Mitigation Recommendations

The fundamental fix is to upgrade to Cisco's official fixed version or apply the official temporary fix package.

General handling recommendations are as follows:

1. Immediately confirm the Unified CM / Unified CM SME version.
2. Check whether the WebDialer service is enabled.
3. If the business does not require WebDialer, disable the service immediately.
4. Upgrade to Cisco's official fixed version.
5. For Release 15 environments that cannot be upgraded immediately, apply the corresponding COP file according to Cisco's guidance.
6. Restrict access sources for the management plane and WebDialer-related services.
7. Add detection for anomalous cmplatform, WebDialer, Axis/WSDD requests on border devices, WAF, IDS/IPS.
8. Check whether anomalous JSP files, anomalous Axis services, or unknown files have appeared.
9. Perform log backtracking on exposed systems, focusing on access records after June 3, 2026.
10. If evidence of file write or command execution is found, treat it as a host compromise, not just a patch upgrade.

15. Summary

The key to CVE-2026-20230 is not the exposure of a single interface, but the trust boundary failure formed by the combinable chain among CUCM WebDialer, cmplatform installation status query logic, internal Axis service processing, and file write capability.

This chain can be summarized as:

Practical exploitability depends on whether WebDialer is enabled, whether the target version is affected, whether hostname filtering can be bypassed, whether the path landing matches, whether the Web container executes the written file, and whether the target has applied patches.

From a defense perspective, it is insufficient to rely solely on "whether a certain JSP file exists" to judge an attack. A more reliable approach is to perform correlation detection across the multi-stage chain: WSDL information gathering, cmplatform anomalous hostname, Axis/WSDD characteristics, path traversal write, JSP landing access, and command parameter access. If multiple stages appear consecutively from the same source within a short time, it should be treated as a high-risk intrusion event.

References

• Cisco Security Advisory: Cisco Unified Communications Manager Server-Side Request Forgery Vulnerability
• NVD: CVE-2026-20230
• SSD Secure Disclosure: Cisco Unified Communications Manager Arbitrary File Write to RCE
• Cisco Unified CM / Unified CM SME Official Upgrade and COP Fix Instructions