Cisco Unified CM Bug Under Active Exploit After PoC Drops Root File-Write Chain

Attackers are now hitting an improper input validation flaw in Cisco Unified Communications Manager and Unified CM Session Management Edition, days after proof-of-concept code surfaced demonstrating an arbitrary file-write primitive that lands as root.

The bug is tracked as CVE-2026-20230 and carries a CVSS v3.1 base score of 8.6. Cisco's advisory describes it as insufficient validation of specific HTTP requests reaching the management interface, allowing an unauthenticated remote attacker to manipulate request parameters in ways the application was never meant to accept.

The exploit path matters more than the score.

The public PoC chains the validation gap into a directory traversal write, then drops a payload into a location executed by a privileged service. Net result: pre-auth remote code execution as root on the call-control plane. For anyone running a Unified CM cluster as the spine of their telephony, that is roughly the worst outcome short of a firmware-resident implant.

Cisco's PSIRT updated the advisory to confirm "attempted exploitation" in the wild (the wording typically used when honeypot or customer telemetry shows hands-on activity but attribution is still soft). No threat actor has been publicly named.

Affected releases include Unified CM and Unified CM SME versions 12.5(1)SU8 and earlier, 14SU3 and earlier, and 15 prior to the fixed engineering special. Cisco's fixed builds are 12.5(1)SU9, 14SU4, and 15SU1 — admins should pin those exact strings when validating patch deployment, because Cisco's release train naming has tripped up more than one change-management ticket.

There is no workaround. Cisco explicitly says so in the advisory, which is the vendor's polite way of telling you the patch is the only door.

The vulnerability was reported through Cisco's coordinated disclosure process by an external researcher credited in the advisory; the PoC that triggered exploitation appeared on a public repository within roughly a week of the patch shipping, following the now-familiar pattern of diffing the fix to recover the bug.

What defenders should do now:

• Patch to the fixed builds above. Do not rely on "close enough" SU numbering.
• Restrict the Unified CM administrative HTTP interface to management VLANs. If it's reachable from a user subnet, assume probing.
• Pull web server and CallManager service logs for anomalous POSTs to administrative endpoints, unexpected file writes under tomcat-owned directories, and new cron or init entries created since the advisory date.
• Rotate credentials and certificates on any cluster you cannot prove was clean prior to patching.

Unified CM sits at the intersection of identity, voice, and (in plenty of deployments) emergency services routing. A root-level foothold there is not a phone problem. It's a domain problem with a phone number attached.