Exploit for CVE-2026-20230

## https://sploitus.com/exploit?id=CCA10CC3-6319-542C-ADD9-3605DA4D116A
# CVE-2026-20230 Cisco Unified Communications Manager SSRF: Arbitrary File Write to RCE—PoC Derivation Process and Analysis

Scope: For use only in local test environments, authorized reproduction environments, vulnerability verification, and analysis of mitigation rules. Do not use against unauthorized targets. This article primarily analyzes the exploit chain, verifiable symptoms, decision logic, and mitigation strategies for CVE-2026-20230; it does not provide attack packets, WebShell content, or command execution payloads that can be directly replicated and executed.

## 1. Vulnerability Background

CVE-2026-20230 is a server-side request forgery (SSRF) vulnerability in Cisco Unified Communications Manager (Unified CM / CUCM) and Cisco Unified Communications Manager Session Management Edition (Unified CM SME). This vulnerability stems from insufficient input validation in the processing of specific HTTP requests. An attacker can construct requests without authentication to cause the affected device to access internal interfaces or local resources on the attacker’s behalf.

The impact of this vulnerability extends beyond standard SSRF probing. Public technical analyses indicate that, under specific version and service configuration conditions, SSRF can be further chained to arbitrary file write capabilities. An attacker can write controlled content to paths on the underlying operating system and then, by leveraging the Web container’s accessible directories or the server component loading mechanism, convert the file write into code execution.

Cisco has assigned a CVSS v3.1 score of 8.6 to this vulnerability, with the following vector:

```text
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N
```

Although the CVSS score is listed as “High,” Cisco has marked the Security Impact Rating for this vulnerability as “Critical.” This is because a successful exploit allows writing to files on the underlying operating system and may further escalate privileges to root.

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; therefore, one cannot simply assume the vulnerability is exploitable based solely on the presence of CUCM assets. A proper risk assessment requires confirming the product version, patch status, WebDialer service status, and whether the relevant interfaces are accessible.

## 2. Why Isn’t It Enough to Simply Check Whether an Endpoint Returns a 200 Response?

This vulnerability is not a typical web vulnerability where the presence of a 200 response upon accessing a specific URL confirms its existence. Its exploitation chain involves at least three layers:

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

Therefore, simply accessing a specific interface and receiving an HTTP 200, 302, 401, 404, or 500 response does not 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 attacks will necessarily bypass filters. The fact that the `installClusterStatusExecute` interface is accessible only indicates the existence of a relevant entry point, but does not, on its own, prove that arbitrary file writing is possible. Conversely, if an exception is returned at any step, it could be due to the target’s version, patches, hostname resolution, path permissions, proxy devices, or service status—and does not necessarily mean the entire exploit chain is inoperable.

A more reliable assessment should combine evidence from multiple stages:

1. Confirm that the target is Cisco Unified CM / Unified CM SME.
2. Confirm that the WebDialer service is enabled.
3. Confirm that the target’s actual hostname or internal service identifier can be obtained.
4. Verify that the SSRF entry point is accessible and that there are signs of the server initiating internal requests.
5. Verify whether evidence of controlled file writing can be generated in an authorized test environment.
6. Assess whether the vulnerability was actually triggered by analyzing server logs, file system changes, web container logs, and alert data.

Only when all of the following conditions are met simultaneously—“WebDialer enabled + affected version + SSRF behavior confirmed + controlled file write confirmed”—should the vulnerability be classified as a highly credible exploit.

## 3. Proof-of-Concept (PoC) Construction Approach

The core of the currently publicly available exploit chain is not simply SSRF, but rather a combined exploitation of SSRF with the Axis/Java Web service mechanisms, log writing, or the processing logic for deployment descriptors.

The overall approach can be summarized as follows:

```text
WebDialer information gathering
↓
Obtain the target’s actual hostname
↓
Trigger SSRF via cmplatform-related interfaces
↓
Access internal WebDialer / Axis management paths
↓
Write or deploy controllable service description content
↓
Create new callable services or file-writing capabilities
↓
Convert the file-writing capability into a Web-accessible script
↓
Achieve command execution under specific conditions
```

From a chain design perspective, the hostname is a critical point. Some filtering logic blocks common local addresses such as `127.0.0.1`, `localhost`, and other common local addresses, but the target’s actual hostname may be allowed to proceed through subsequent request flows. Therefore, the PoC first extracts the actual hostname from WebDialer’s WSDL information and then uses it as the internal access prefix in the SSRF chain.

The second key point involves the logic related to the Axis service. The PoC does not upload files directly to the web directory; instead, it utilizes the internal service processing chain to cause server-side components to write attacker-controlled content to a specific path. This process is essentially a combination of “internal server requests + component configuration/log writing behavior + path traversal/path control.”

The third key point is the two-stage write process. The first stage is typically used to establish a more stable entry point for file writing, while the second stage writes the command-execution script to a Web-accessible directory. The reason for this approach is that writing the complete command-execution logic in a single step via SSRF may be affected by encoding, length, XML structure, path permissions, and server parsing behavior, whereas the two-stage method makes it easier to split complex payloads.

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

```text
External Request Entry Point: Interfaces related to cmplatform installation status
Information Retrieval Entry Point: WebDialer WSDL / services-related interfaces
Internal forwarding targets: WebDialer / Axis / AdminService-related paths
Key behaviors: SSRF, internal server requests, controlled file writing, and deployment of Web-accessible files
Ultimate risks: arbitrary file writing, WebShell deployment, command execution, and paths to root privilege escalation
```

## 4. Logic for Obtaining the Hostname

The PoC must first obtain the target’s actual hostname, rather than relying solely on the IP address or an external domain name.

This is because SSRF filtering logic does not necessarily evaluate only the final connection target; it may also validate the hostname field, the URL string, and keywords related to local addresses. Common local addresses such as `127.0.0.1` and `localhost` may be blocked, whereas the device’s actual hostname may be considered a valid hostname in certain scenarios.

Interfaces that can be used to assist in this determination are typically related to WebDialer WSDL information. When accessing this type of WSDL, the response may contain the service address, the `location` field, or other resolvable 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 phase of the SSRF attack.

The criteria for evaluation at this stage should be:

1. Is the WSDL interface accessible?
2. Does the response content match the characteristics of a WebDialer or Axis service?
3. Can the actual hostname be resolved from the response?
4. Does the resolved hostname differ from the externally accessible IP address or domain name?
5. Can this hostname be accepted by subsequent SSRF entry points?

If hostname resolution fails, the PoC may fall back to the target IP address, but this significantly reduces the success rate. In real-world environments, common causes of hostname resolution 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 Phase

The SSRF trigger point is located in the logic for querying the installation status of cmplatform-related components. This feature is intended to query the installation status of cluster nodes; the server constructs internal requests based on the node ID or hostname submitted by the user.

The core vulnerability lies in the fact that the hostname parameter, which is under the attacker’s control, is not strictly restricted to valid node names or trusted hosts, allowing it to be constructed into more complex internal access paths. The server then initiates a request to the internal interface on behalf of the attacker.

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

1. Bypassing external network access restrictions to reach service endpoints that are normally accessible only by the local machine or internal components.
2. Leveraging the trust boundaries of internal services to transform ordinary HTTP parameters into operations on internal components.

During authorization verification, one cannot determine the success of an SSRF attack based solely on HTTP status codes. More reliable evidence includes:

1. Access logs to internal paths appearing in server logs.
2. Characteristics of internal interfaces appearing in the request-response content.
3. Traces of new or anomalous services appearing on subsequent WebDialer services pages.
4. The presence of anomalous files created by server processes in the file system.
5. Security devices detecting anomalous paths, encoded content, or internal service paths within the `hostname` parameter.

## 6. Approach to Writing to Axis Services and Arbitrary Files

On public networks, SSRF is further exploited to access Axis-related service interfaces and attempt to write to the service deployment description. Attackers construct special XML/WSDL structures to force server-side components to write controllable content to specified paths during processing.

The essence of this phase is not traditional file upload, but rather the abuse of the server-side component’s processing logic:

```text
User-Controllable Parameters
↓
SSRF Internal Request
↓
Axis / Web Service Processing
↓
Writing of Controllable Deployment Descriptions or Logs
↓
File Generation at Specified Path
```

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

1. Writing to the target path typically requires traversing to a directory accessible by the web container.
2. The written content must conform to the server component’s processing format; otherwise, it may only result in an invalid file.
3. The owner and permissions of the written file depend on the Tomcat / CUCM service process.
4. If the write location is accessible via the Web, the file write may further escalate to script execution.
5. Even if the write location is not executable, it may still result in configuration corruption, persistence, or conditions for subsequent privilege escalation.

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

## 7. Two-Stage WebShell Write Logic

PoC designs typically employ a two-stage write process rather than executing commands in a single step.

The first stage is used to establish a basic file-writing capability. The goal of this stage is to allow the attacker to write content to a specified location on the server via a web-accessible path.

The second stage leverages the write capability established in the first stage to write a command execution script to a web-accessible directory. The attacker can then trigger system command execution via HTTP parameters.

The advantages of the two-stage design are:

1. Reduces the complexity of the payload in a single SSRF request.
2. Avoids payload corruption caused by XML, URL encoding, or special character escaping.
3. Separates “service deployment” from “writing the final executable file,” facilitating debugging.
4. Makes it easier to adjust the drop location across different target paths.
5. Decouples the subsequent command execution phase from the SSRF phase.

However, from a defense perspective, the two-stage write approach also provides a clearer detection surface:

1. The first abnormal request typically attempts to create a new service or write to an intermediate JSP.
2. The second abnormal request typically accesses the intermediate JSP and carries parameters such as filenames and file content.
3. The third phase accesses the final command execution JSP and carries authentication passwords or command parameters.
4. Web access logs will show a pattern of consecutive accesses within a short timeframe to paths such as WebDialer, services, axis2-web, and platform-services.
5. The file system may contain anomalous JSP files, unusual service names, suspicious log files, or newly added web resources.

## 8. Complete Execution Flow of the Current PoC

The process of the current PoC can be summarized as follows:

1. Resolve the target address.
2. Access the WebDialer WSDL to attempt to extract the actual hostname.
3. Construct an SSRF request targeting the internal WebDialer / Axis management path.
4. Write content related to the Axis service via an internal request.
5. Access the “services” page to verify whether the abnormal service has been successfully deployed.
6. Call the new service to write the first-stage file-writing script.
7. Access the first-stage script to write the second-stage command-execution script.
8. Access the second-stage script and execute the test command.
9. Determine whether the exploit was successful based on the HTTP response, file drop results, and command output.

In terms of exploit success rates, the most critical failure points typically include:

1. WebDialer is not enabled.
2. Hostname resolution fails or is filtered.
3. The SSRF request does not actually reach the internal service.
4. Axis service deployment fails.
5. The path-traversal drop location is incompatible with the target version.
6. The web directory is not writable, or the script is not executed.
7. The target has been patched or is using a Cisco temporary fix package.
8. Proxies, WAFs, EDRs, or file integrity monitoring block intermediate stages.

Therefore, while this PoC has a high exploitability rate when specific vulnerable versions and default paths match, it is not a guaranteed exploit for all CUCM assets.

## 9. Logic for Determining Success

Determining the success of CVE-2026-20230 cannot be based solely on whether the script completes execution. A more reasonable assessment should be divided into four tiers.

### Tier 1: Target Suspected to Be Exposed

Conditions are:

```text
WebDialer WSDL is accessible
or the services page is accessible
or cmplatform-related APIs are accessible
```

This only indicates that the target has a relevant attack surface; it does not prove that the vulnerability is exploitable.

### Tier 2: Suspected Vulnerability

Conditions:

```text
The target’s version is within the affected range
WebDialer is enabled
The hostname can be resolved
The SSRF entry point returns an anomalous but plausible server response
```

In this case, further verification should be conducted using server logs or an authorized test environment.

### Tier 3: Confirmed File Write

Conditions:

```text
A controlled file appears on the server following an SSRF attack
or an anomalous file created by a server process appears in the web directory
or an anomalous new service appears on the services page
or logs contain descriptions of controlled deployments
```

Upon reaching this level, it can be confirmed that the exploit chain has progressed beyond the standard SSRF stage and entered the realm of arbitrary file write risk.

### Level 4: RCE Confirmation

Conditions:

```text
The written, web-accessible script is successfully parsed and executed
and the server’s execution results can be observed via authorized test commands
```

Only at this stage can remote command execution be confirmed. Successful file writing does not necessarily equate to successful RCE; however, in high-privilege service environments such as CUCM, file writing 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 a controlled environment, it is recommended to prioritize “read-only checks” or “non-destructive verification” methods, such as:

```bash
python3 CVE-2026-20230-check.py https://127.0.0.1 --check
```

Recommended checks include:

1. Is the target a Cisco Unified CM or Unified CM SME?
2. Is the WebDialer service enabled?
3. Is the WSDL accessible?
4. Is the “services” page exposed?
5. Is the target version older than the patched version?
6. Are there any signs of unusual new JSP files, unusual Axis services, or unusual log entries?

It is not recommended to perform full file-writing or command-execution verification on production systems. Even for authorized testing, it should be conducted primarily in isolated testbeds, snapshot environments, or within the vendor’s recommended verification processes.

## 11. Security Boundaries in PoC Design

The security boundaries for this type of PoC must be clearly defined.

First, command execution should not be performed by default. The command execution phase is a high-risk verification step that can easily result in changes to the system state, log tampering, service abnormalities, or triggered responses from security devices.

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

Third, do not perform bulk scanning of public-facing targets. Since this vulnerability does not require authentication and the targets are primarily enterprise communication infrastructure, the risks associated with unauthorized scanning and exploitation are extremely high.

Fourth, the testing mode should be separated from the exploitation mode. It is recommended to split the PoC into two scripts: one used solely for asset identification and service status assessment, and the other used exclusively to verify file writing within a local sandbox or explicitly authorized environment.

Fifth, the scope of targets should be restricted. The PoC can incorporate protective mechanisms such as local IP addresses, private subnets, whitelisted domains, and authorization confirmation parameters to prevent accidental attacks on third-party systems.

Sixth, the RCE phase should be disabled by default. Even if research code is retained, users should be required to explicitly provide authorization confirmation parameters before proceeding to file write or command execution verification.

## 12. Insights for Writing Protection Rules

From a traffic detection perspective, rules should not rely solely on matching a specific filename, service name, or JSP name. Service names, filenames, and paths in publicly available PoCs can be modified, making single-string rules prone to false negatives.

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

### Category 1: Information Gathering Stage

Key Focus Areas:

```text
/webdialer/Version.jws?wsdl
/webdialer/services
WebDialer WSDL
Axis services listing
```

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

### Category 2: SSRF Trigger Phase

Key Focus Areas:

```text
/cmplatform/installClusterStatusExecute
action=clusterNodeInstallStatus
Abnormal increase in the `hostname` parameter
URL-encoded path separators appearing in the `hostname` parameter
The `hostname` parameter contains internal path characteristics such as `webdialer`, `services`, `AdminService`, `platformcom`, and `installstages`
```

The key indicator in this stage is that the `hostname` parameter no longer resembles a standard hostname but exhibits characteristics of path-like, URL-like, encoded, or XML-like structures.

### Category 3: Axis / WSDD Injection Stage

Key Focus Areas:

```text
deployment
wsdd
java:RPC
requestFlow
LogHandler
allowedMethods
className
fileName
writeToConsole
```

When these fields appear together, there is strong reason to suspect that an attacker is attempting to write controllable content via the Axis service deployment descriptor.

### Category 4: File Writing Phase

Key Focus Areas:

```text
axis2-web
platform-services
JSP file writing
Combinations of filenames and file contents appearing in parameters
Web directory path traversal
common/log/taos-log-a
tomcat/webapps
```

If attack traffic contains a large number of `../` sequences, URL-encoded path traversal, JSP file extensions, or Tomcat WebApp paths, it should be classified as high-risk.

### Category 5: Command Execution Phase

Key Focus Areas:

```text
New JSP pages accessed
Command parameters such as `pwd`, `cmd`, `command`, `exec`, or `i` appearing in request parameters
System command output formats appearing in the response
A single source IP address performing a sequence of actions—WSDL retrieval, SSRF, write, and execution—within a short timeframe
```

From a rule design perspective, a phased detection approach is recommended:

1. WebDialer information gathering: Low- or medium-risk alert.
2. cmplatform SSRF with abnormal hostname: High-risk alert.
3. Combination of Axis/WSDD/LogHandler signatures: Critical alert.
4. JSP file write or command execution parameters: Critical alert.
5. Multi-stage correlation match: Escalate directly to an intrusion event.

## 13. Troubleshooting and Forensic Investigation Recommendations

During emergency troubleshooting, focus on checking the following locations and phenomena:

1. Check WebDialer access logs for abnormal WSDL and service enumeration.
2. Check the cmplatform access logs for any abnormal `installClusterStatusExecute` requests.
3. Check whether the `hostname` parameter contains URL-encoded content, path traversal, Axis, WSDD, LogHandler, or similar elements.
4. Check whether any abnormal JSP files have appeared in the Web directory.
5. Check whether any abnormal service names have appeared on the Axis services page or in the configuration.
6. Check whether any abnormal deployment descriptions, XML parsing errors, or path write records have appeared in the Tomcat logs or platform service logs.
7. Check whether test files or unknown files have appeared in the `/tmp` directory, the WebApp directory, or the log directory.
8. Check whether there have been multiple consecutive access attempts originating from the same source IP address within a short period of time.
9. Check for traces of abnormal system command execution, process creation records, or shell-related behavior.
10. Check for any suspicious files, scheduled tasks, startup items, or persistent traces related to root privileges.

If you suspect the system has been compromised, prioritize isolating administrative access, preserve log and filesystem evidence, and then proceed with applying patches, removing WebShells, cleaning up suspicious services, and rotating accounts/credentials.

## 14. Remediation and Mitigation Recommendations

The fundamental remediation is to upgrade to the official Cisco patch release or apply the temporary fix package provided by Cisco.

General remediation recommendations are as follows:

1. Immediately verify the Unified CM / Unified CM SME version.
2. Check whether the WebDialer service is enabled.
3. If WebDialer is not required for business operations, disable the service immediately.
4. Upgrade to the official Cisco patch release.
5. For Release 15 environments where an immediate upgrade is not possible, apply the corresponding COP file according to Cisco’s guidelines.
6. Restrict the sources of access to the management interface and WebDialer-related services.
7. Add detection for anomalous requests targeting cmplatform, WebDialer, and Axis/WSDD on perimeter devices, WAFs, and IDS/IPS systems.
8. Check for any anomalous JSPs, abnormal Axis services, or unknown files.
9. Perform log analysis on exposed systems, focusing on access records from June 3, 2026, onward.
10. If evidence of file writing or command execution is found, treat the system as compromised rather than simply applying the patch.

## 15. Summary

The critical issue with CVE-2026-20230 lies not in the exposure of a single interface, but in the chained failure of trust boundaries formed between the CUCM WebDialer, the cmplatform installation status query logic, the internal Axis service handling, and the file-writing capability.

This chain can be summarized as follows:

```text
Unauthenticated external request
↓
Confirmation of WebDialer exposure
↓
Retrieval of actual hostname
↓
cmplatform SSRF
↓
Access to internal Axis service
↓
Controllable service description or log writing
↓
Web-accessible file drop
↓
Risk of command execution and root privilege escalation
```

Actual exploitability depends on whether WebDialer is enabled, whether the target version is vulnerable, whether hostname filtering can be bypassed, whether the file path matches, whether the web container executes file writes, and whether the target has been patched.

From a defensive perspective, one should not rely solely on the “presence of a specific JSP file” to detect an attack. A more robust approach involves correlative detection across the multi-stage attack chain: WSDL information retrieval, abnormal cmplatform hostnames, Axis/WSDD signatures, path traversal writes, JSP file download access, and command parameter access. If multiple stages occur consecutively from the same source within a short period of time, the incident should be treated as a high-risk intrusion.

## 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 Notes