• CVE-2026-20230
• CVSS v3.1 8.6 (Cisco Critical)
• Pre-Auth
• CISA KEV (added 2026-06-25, active exploitation since 2026-06-21)

Cisco Unified Communications Manager — formerly CallManager — is the most widely-deployed enterprise IP-PBX in the world. A typical deployment clusters one publisher with several subscribers across two data centers, running Cisco’s Linux appliance OS, and serves SIP registration, call control, voicemail, presence, conferencing, and PSTN gateway peering for the whole organization. It is one of the few hosts on the corporate network with persistent trusted reach into the executive suite — the CEO’s voicemail, the board-meeting bridge, and the executive-floor handsets all live there.

Under the hood CUCM is a Java stack: the admin tier runs on Apache Tomcat alongside the WebDialer Click-to-Call service and a Cisco fork of Apache Axis2. Axis2 hot-deploys .aar service archives from a directory on the filesystem — the mechanism that lets the chain end at root once the attacker can write into that directory.

CVE-2026-20230 is a pre-authentication SSRF in the WebDialer makeCall handler. A single SOAP POST to TCP/8443 with a file:// URI in the hostname field turns into an arbitrary-file-write primitive, then a rogue Axis service, then a JSP webshell, then root on the publisher — persistent across reboots and reachable through the cluster trust channel to every subscriber.

CISA added the bug to its Known Exploited Vulnerabilities catalog on 2026-06-25 with a Federal Civilian Executive Branch remediation deadline of 2026-06-28. Defused Cyber observed file:// payloads landing on CUCM honeypots since the weekend of June 21–22; SSD Secure Disclosure published the technical writeup shortly after. By the time most SOCs read this article, exploit code has been public for over a week and the federal deadline has already passed.

The chain composes four defects — pre-auth reachability of an internal SOAP endpoint, an SSRF with no URI-scheme allow-list (CWE-918), an Axis container that hot-deploys attacker-supplied services, and a tomcat → root sudoers gap known to the community for years. None of them is a Critical CVE on its own; composed in order, they collapse “send one HTTPS request, no credentials” to “root on the phone system” in a single Python script that has been on GitHub since disclosure.

What is WebDialer and Why Is It On?

WebDialer is a Click-to-Call SOAP service that ships with Cisco Unified CM. Its purpose is to let a desktop application — typically a CRM like Salesforce, ServiceNow, or Microsoft Dynamics — make a single SOAP call to CUCM that places an outbound call from the user’s IP phone to a number the desktop app supplies.

The end-user clicks a phone-number link in their CRM, their handset rings, they pick up, the call is dialed. It’s a horizontal integration feature that drives Cisco’s sales pitch to enterprise customers running CRM-integrated contact centers.

WebDialer is disabled by default on a fresh CUCM install — this is the mitigating fact that keeps the chain from being a 9.8 CVSS score. But it is enabled in essentially every deployment that has ever sold a Click-to-Call integration into the organization.

Sales-heavy organizations, call-center operations, customer-support teams, executive-assistant pools — anywhere a user benefits from clicking a phone number on their screen and having their handset dial it — runs WebDialer in production. Cisco’s own deployment documentation walks the administrator through enabling it. The disabled-by-default posture is real; the enabled-in-practice posture is the world most CUCM deployments actually live in.

The vulnerable code path is the makeCall SOAP handler in the WebdialerSoapImpl service. The handler accepts a hostname field meant to identify the calling user’s handset on the SIP signaling network.

In the patched code the field is validated against a regular expression that matches valid SIP hostnames. In the pre-patch code the field is fetched directly via a URI loader — whatever the attacker puts in the field is opened by the application’s HTTP client.

The HTTP client is a generic Java URI loader; it honors any scheme registered with the JVM. http:// and https:// are honored, of course. So is file://. So is jar://, ftp://, ldap://, and a long tail of others that have been used in SSRF chains in other Java applications for over a decade.

The Attack Chain – Overview

Four cards, three pivots, one unauthenticated HTTPS POST. Each step removes the cap installed by the previous defense layer — the chain works because each layer assumed the layer behind it was enforcing security.

Step 1 — The attacker. Unauthenticated. No Cisco account, no Unified CM administrator role, no session. The attacker reaches the CUCM web tier on TCP/8443 over the public network — or, in many enterprise deployments, an internal network reachable from a single compromised endpoint.

The only pre-work is a SOAP probe that retrieves the system’s true hostname — a value the SSRF payload in the next stage will reference back to.

Step 2 — SSRF via WebDialer (CVE-2026-20230). A crafted SOAP POST to the WebDialer endpoint (/webdialer/services/WebdialerSoapImpl) supplies a hostname field whose value is a file:// URI rather than a host or a URL. WebDialer’s makeCall handler is supposed to dial a destination using the hostname as the SIP routing target; in practice it fetches and processes the supplied URI without validating the scheme.

file:// is honored. WebDialer can read or write any path the application JVM has access to. WebDialer is disabled by default on a fresh CUCM install, but it is enabled in any deployment that uses Click-to-Call from Salesforce, ServiceNow, Microsoft Teams, or any number of CRM integrations — which is most enterprise deployments.

Step 3 — Install a rogue Apache Axis service + JSP file-writer. Using the file-write primitive, the attacker writes an Axis service definition (FileWriter.aar) into CUCM’s Axis webapps directory. Axis’s hot-deploy scanner picks up the new service within roughly a minute and exposes it on the same port as the SOAP API.

The service implements a write(path, base64_content) method — an arbitrary-file-write capability bridged to the HTTP boundary. From this point the attacker no longer needs the SSRF; they have a stable file-write API.

Step 4 — Remote code execution. The attacker uses the file-write API to drop a small JSP webshell into /usr/local/cm/tomcat/webapps/axis2-web/cucm.jsp. The webshell is reachable over HTTPS on 8443 with no further authentication required.

Initial execution lands as the tomcat user; the well-known CUCM hardening gap (tomcat has sudo rights so Cisco’s own update tooling can run as root) gets the attacker to UID 0 in one additional shell command.

The footprint is persistent across reboots, reaches every other node in the CUCM cluster through the trusted intra-cluster channel, and gives the attacker control over voice traffic, AD-integrated phonebook lookups, executive voicemail, conferencing recordings, and PSTN gateway routing.

At a glance. CVSS v3.1 8.6 (Cisco rates the bug Critical despite the sub-9.0 score because the chain ends at root). Affected: Cisco Unified CM and Unified CM Session Management Edition deployments with WebDialer enabled. Fixed: see Cisco Security Advisory cisco-sa-cucm-ssrf-cXPnHcW for the per-branch patched-build matrix. Required identity: none — pre-auth. User interaction: none. Wire signature: a SOAP POST to /webdialer/services/WebdialerSoapImpl whose hostname field contains a file:// URI. ## Exploitation

The Exploitation 

Hostname Enumeration

The chain’s first call is a benign-looking SOAP probe whose only purpose is to retrieve the CUCM publisher’s true hostname. The attacker needs the hostname because the SSRF payload in Step 2 references it back to the system; calling the SSRF with the wrong hostname returns an error rather than reading the file. This is not a vulnerability in its own right — the hostname is disclosed by design over the same SOAP API — but it is an indispensable enumeration step.

Caption: A SOAP POST with hostname=__retrieve__ returns the system’s actual hostname in the response body. The attacker captures it for the SSRF payload in the next step. No authentication is required; the SOAP API is open to anyone reachable on TCP/8443.

Fire the SSRF via file:// URI

With the hostname captured the attacker fires the actual SSRF. The payload is a SOAP envelope whose hostname field contains a file:// URI pointing at the desired write target. The response from the server is a generic “OK” — the SSRF’s success is silent at the HTTP layer; the attacker confirms the write by looking for the file on the target through any side channel they can arrange.

Caption: The SSRF payload. The hostname field is a file:// URI rather than a SIP hostname; WebDialer’s URI loader fetches and processes it without validating the scheme. The server returns 200 OK with a normal-looking response; the actual side effect — the file write — happens silently on the filesystem.

Install a Rogue Apache Axis Service

The SSRF gives the attacker a file-write primitive, but reading the contents of newly-written files through the same SSRF is awkward — the file:// URI loader’s behavior on subsequent reads is inconsistent between Java versions. Rather than make the chain depend on the read-back path, the attacker stages a sturdier file-write primitive on top of the SSRF: they write an Apache Axis service archive (FileWriter.aar) into CUCM’s hot-deploy directory.

file:// SSRF target:
  /usr/local/cm/tomcat/webapps/axis2/WEB-INF/services/FileWriter.aar

CUCM’s Axis2 container scans this directory on a fixed interval (60 seconds by default) and hot-deploys any new .aar it finds. Within a minute the attacker’s FileWriter service is live and reachable at /axis2/services/FileWriter?wsdl. The service implements a single SOAP method — write(path, base64_content) — that writes attacker-supplied bytes to any path the Tomcat user (tomcat, UID 503 by default) can write.

Caption: The exploit script writes the Axis service archive through the SSRF and polls the Axis admin endpoint until the service appears. From this point forward the attacker has a clean, repeatable file-write API; the SSRF only needed to fire once.

Drop a Webshell, Escalate to Root

With the file-write API in place the attacker drops a small JSP webshell into the Axis2 web directory:

/usr/local/cm/tomcat/webapps/axis2-web/cucm.jsp

Tomcat serves the JSP immediately — no class-loader scan required — and the webshell is reachable over HTTPS on 8443 at https://target:8443/axis2-web/cucm.jsp?cmd=<command>. The first command runs as the tomcat user. The escalation to root then follows the well-known CUCM tomcat → root path: Cisco’s own update tooling requires tomcat to be able to invoke certain administrative scripts via sudo, and the sudoers policy on stock CUCM deployments grants tomcat NOPASSWD: ALL for those scripts. The exact policy varies by patch level; on most deployments the attacker can simply run sudo id and land at uid=0(root) in one shot.

Caption: The full chain firing. The exploit script drops the JSP webshell through the Axis file-writer; the webshell responds to HTTPS GET requests with the output of attacker-supplied shell commands; the first call returns uid=503(tomcat); the second uses the CUCM sudoers gap to land uid=0(root). The webshell is persistent: it survives CUCM service restarts, survives reboots, and propagates through the cluster trust channel to subscribers. The attacker now controls voice traffic, voicemail, conferencing, and the PSTN gateway peering for the entire organization.

Verification Against the Patched Build

Re-firing the Step-2 SSRF against a CUCM build that has applied the Cisco advisory’s patch returns HTTP 400 with a SOAP fault explaining that the URI scheme is not in the allow-list. The patch enforces an allow-list of schemes (http, https) at the WebDialer entry point. Without the SSRF in Step 2, the chain has no file-write primitive; without the file-write primitive there is no Axis service install; without the Axis service there is no webshell drop. The chain breaks at its earliest point.

Caption: The same SSRF payload, fired against a patched CUCM. The server returns 400 with faultstring: hostname URI scheme not in allow-list (http, https only). The chain does not progress.

Public PoCs

SSD Secure Disclosure published the technical writeup that explains the chain. Public PoC code has been observed in the wild since the weekend of June 21–22, 2026 — Defused Cyber characterized the exploitation pattern as “a single source using an unvetted PoC, with genuinely-formatted file:// file-write payloads landing on our decoys.” The PoC code’s quality is inconsistent (the SSD writeup describes the chain end-to-end; the public code drops on GitHub fork networks that occasionally implement only the file-write primitive without the Axis-install stage), but the SSRF entry point is universal and the file-write primitive is sufficient for any attacker with even passing Java/JSP familiarity to complete the chain.

Static Analysis

The Vulnerable Endpoint

The vulnerable code path is the makeCall SOAP method in com.cisco.ccm.webdialer.WebdialerSoapImpl, exposed at /webdialer/services/WebdialerSoapImpl on the CUCM Tomcat instance (TCP/8443 in default deployments).

The method takes a SOAP envelope whose body contains a hostname parameter intended to identify the calling user’s SIP handset. In the pre-patch code the handler passes the field to a generic Java URI fetcher to resolve the SIP routing target.

The URI fetcher is a URL.openConnection() call. It honors whichever URI scheme is registered with the JVM — on a stock CUCM JVM that includes http, https, file, jar, ftp, mailto, and a handful of others. file:// is honored without restriction.

When the attacker supplies file:///path/to/destination, the URI fetcher opens the path with read+write semantics, and any body content the SOAP request carries is written to it.

The makeCall Handler — Reconstructed

Recovered from decompilation of the pre-patch WebdialerSoapImpl.class inside webdialer.war (deployed under /usr/local/cm/tomcat/webapps/webdialer/WEB-INF/classes/), the handler is approximately:

jd-gui decompilation of the pre-patch WebdialerSoapImpl.makeCall method, highlighting the raw new URL(hostname) call, the URLConnection open, and the setDoOutput true that enables the file-write primitive when the scheme is file://.

Decompiled pre-patch handler. Three defects visible in one method: no scheme validation on new URL(hostname), URLConnection.setDoOutput(true) on an attacker-supplied URL, and a body write that happens before the response is even read.

Three details of this method combine into the SSRF-to-file-write primitive:

• No scheme validation before new URL(hostname). The Java URL class accepts every scheme registered with the JVM’s URLStreamHandlerFactory, including file. Anything reachable to the JVM’s URL loader is reachable from this handler.
• URLConnection.setDoOutput(true) on a file:// URL turns the connection into a writer against the target path. The connection’s OutputStream writes bytes into the file with the permissions of the running JVM — on stock CUCM, the tomcat user.
• The write happens before the response is even read. By the time the InputStream open fails (or succeeds), the file has already been written. The SOAP fault returned to the attacker is a side channel; the primary effect is the on-disk artifact.

The Axis2 Hot-Deploy Directory

CUCM ships with a fork of Apache Axis2 hosted as a Tomcat web application under /usr/local/cm/tomcat/webapps/axis2/. Axis2’s standard hot-deploy behavior — scanning WEB-INF/services/ for new .aar archives every 60 seconds and registering any new services it finds — is enabled and unmodified in the CUCM distribution.

The directory permissions are configured so the tomcat user has write access — this is required for Cisco’s own administrative tooling to publish services into it. Anything that can write to that directory as tomcat can register an arbitrary new SOAP service.

The tomcat → root Sudoers Gap

On stock CUCM deployments the tomcat user’s sudoers policy grants NOPASSWD access to a set of Cisco administrative scripts: certificate management, service-restart helpers, log-rotation tools, and several others. The set varies by patch level.

Several of those scripts accept attacker-controlled arguments (file paths, certificate names, log-file selectors) that are passed through to root-context shell commands without sanitization. Following the community CUCM hardening guides published since 2019, the most reliable escalation path is to invoke the certificate-rotation script with a crafted –cert-path argument that includes a ; shell metacharacter.

Cisco’s official guidance has long been to enforce sudoers password prompts for these scripts on production CUCM deployments — guidance that published CISO-survey data suggests is followed on roughly half of in-production CUCM clusters.

Root Cause Analysis

The four defects the chain composes are not bugs in any single line of code — they are combined design decisions that meet across two Cisco product teams. The taxonomy:

Step 1+2 — SSRF: missing URI-scheme allow-list. The WebDialer makeCall handler passes the user-supplied hostname field through a Java URI fetcher without validating the scheme. CWE-918 Server-Side Request Forgery.

The fix is to enforce an allow-list of schemes (http, https) at the WebDialer entry point — exactly what the patch does. The fix is correct and sufficient for this CVE.

Step 3 — Axis2 hot-deploy from a directory writable by the Tomcat user. The Axis2 container hot-deploys .aar archives from a directory the Tomcat user can write to. CWE-732 Incorrect Permission Assignment for Critical Resource.

The fix is to make the hot-deploy directory read-only to the Tomcat user — service registration would then have to go through an administrative path running as a different user. Cisco has not applied this hardening; the directory remains writable to tomcat in the patched build.

Step 4 — tomcat → root sudoers gap. The tomcat user has NOPASSWD sudo rights to administrative scripts that pass attacker-controlled arguments to root-context shells. CWE-269 Improper Privilege Management.

The community-known hardening — enforce sudoers passwords for the affected scripts, or remove the wildcard arguments from the sudoers policy — has been published since 2019 and is not applied by default on stock CUCM installs. Cisco has not changed the default in the patched build for this CVE.

Step 1 — Pre-auth reachability of an internal SOAP endpoint. The WebDialer SOAP API is reachable without authentication on TCP/8443 in default deployments. CWE-862 Missing Authorization.

The fix is to require Click-to-Call user authentication before the SOAP API will accept calls. Cisco has historically rejected this fix on the grounds that the Click-to-Call workflow needs the API open to the calling user’s desktop app, which usually does not present credentials; the patched build leaves this open.

The structural lesson is that the patch fixes the entry point but leaves three latent layers in place. CWE-918 is the only defect the patch addresses; CWE-732, CWE-269, and CWE-862 remain. Any future bug that recreates pre-auth reachability of a file-write primitive will land at root via the same chain.

The pattern — patching the reachable surface, leaving the depth-of-defense gaps in place — is consistent across the published Cisco advisories for the past five years. It is the structural reason CUCM has appeared in CISA’s Known Exploited Vulnerabilities catalog four times in twenty-four months.

Patch Diffing

Cisco published the patched builds on the schedule documented in advisory cisco-sa-cucm-ssrf-cXPnHcW. The patched per-branch build numbers vary by deployment vintage; the per-branch table is in the advisory.

The fix lives in a single class — com.cisco.ccm.webdialer.WebdialerSoapImpl — and is a small change in concept: introduce a URI-scheme allow-list, apply it before the URI fetcher runs, and return an explicit SOAP fault on rejection.

The conceptual diff:

// VULNERABLE (pre-patch)
public CallResponse makeCall(String hostname, String destination) {
    URL u = new URL(hostname);                  // <-- accepts any scheme the JVM honors
    URLConnection c = u.openConnection();
    InputStream in = c.getInputStream();
    // ... rest of call routing
}

// PATCHED
public CallResponse makeCall(String hostname, String destination) {
    URL u = new URL(hostname);
    String scheme = u.getProtocol();
    if (!ALLOWED_SCHEMES.contains(scheme.toLowerCase())) {     // <-- new
        throw new SOAPFault(
            "Client",
            "hostname URI scheme not in allow-list (http, https only)"
        );
    }
    URLConnection c = u.openConnection();
    InputStream in = c.getInputStream();
    // ... rest of call routing
}

private static final Set<String> ALLOWED_SCHEMES =
    new HashSet<>(Arrays.asList("http", "https"));

The fix is correct, surgical, and sufficient for CVE-2026-20230. It breaks the chain at the first stage; without file:// reachability the file-write primitive does not exist; without the file-write primitive the rest of the chain has no entry point.

The fix does not harden Stages 3 and 4. The Axis2 hot-deploy directory remains writable to tomcat. The tomcat → root sudoers gap remains as it was.

Any future CVE that recreates pre-auth reachability of a file-write primitive — through a different endpoint, a different parameter, a different bug entirely — will land at root via the same downstream chain. The Cisco CUCM patch is what defenders need today; the broader hardening posture is what defenders need for the next CVE to drop.

Conclusion

Impact

The chain allows an unauthenticated network-reachable attacker to execute arbitrary code as root on a Cisco Unified Communications Manager publisher. CUCM is the unified-communications backbone of the enterprise — voice traffic, voicemail, conferencing, presence, AD-integrated phonebooks, PSTN gateway peering, and the executive-suite handset registrations all live on it.

A root compromise of the publisher lets the attacker read every voicemail message stored in Unity Connection, record any active call by patching the call-recording configuration, forward executive calls to attacker-controlled destinations, add fraudulent destinations to the dial plan and place outbound calls billed to the organization’s PSTN carrier, and pivot through the cluster trust channel to every subscriber node in the deployment.

In organizations that have integrated CUCM with Active Directory — most of them — the AD service account configured for the integration is typically over-permissioned for the actual integration’s needs. A root attacker on the CUCM publisher can read the credentials of that service account from the configuration database and use them against AD. The phone system, once compromised, frequently becomes the on-ramp to the rest of the enterprise.

The takeaway

The Cisco Unified CM CVE-2026-20230 chain teaches the same structural lesson as the Splunk PostgreSQL sidecar, the LiteLLM authorization chain, the Veeam BinaryFormatter family, and every other recent “compromise the trusted-infrastructure host” CVE: a phone-system compromise is a compromise of the enterprise communications backbone, and the defender community has been treating phone systems as if they were unimportant because they don’t directly hold cardholder data. They hold something almost as valuable — the trust path into every other system in the network. SIEMs, backup servers, identity providers, AI gateways, CI/CD systems, and now phone systems are all in the same class of crown-jewel infrastructure. They each hold the keys to systems they were never built to protect from. The defensive playbook has to catch up. Treat the CUCM publisher with the same skepticism you would treat an exposed domain controller. Network-segment it. Authenticate the management plane. Disable services you do not need. Most importantly, when the next chain appears in this same surface — and one will — be ready to apply the same hardening posture on day zero, not day fourteen.

References

• Cisco Security Advisory cisco-sa-cucm-ssrf-cXPnHcW — https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cucm-ssrf-cXPnHcW
• NVD entry for CVE-2026-20230 — https://nvd.nist.gov/vuln/detail/CVE-2026-20230
• CISA Known Exploited Vulnerabilities catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• SecurityWeek — Hackers Exploiting Cisco Unified CM Vulnerability — https://www.securityweek.com/hackers-exploiting-cisco-unified-cm-vulnerability/
• SOCRadar — CVE-2026-20230: Cisco Unified CM WebDialer SSRF Can Lead to Root-Level Compromise — https://socradar.io/blog/cve-2026-20230-cisco-unified-cm-webdialer-ssrf/
• SSD Secure Disclosure — Cisco Unified CM SSRF technical writeup — https://ssd-disclosure.com/
• Threat-Modeling.com — Cisco Unified CM SSRF to Root: Exploit Code Publicly Available — https://threat-modeling.com/cisco-unified-cm-ssrf-root-cve-2026-20230/