I read the Cisco advisory and the public reports on CVE-2026-20045. It is a remote code execution flaw in Cisco Unified Communications products, and it is being actively exploited. The sensible response is to treat exposed UC kit as high priority while you patch.
CVE-2026-20045 allows unauthenticated remote attackers to gain code execution, escalate from user to root, and run arbitrary commands. Cisco lists Unified Communications Manager, Unity Connection and Webex Calling Dedicated Instance among affected products. The reported CVSS score is 8.2. Some releases have patches available. Cisco will not backport fixes for older releases such as 12.5, so those systems need migration planning rather than a simple patch.
Start with inventory. Record every Cisco UC instance you run or manage, along with the exact product, version and patch level. Check whether each one is internet-facing. Look at NAT rules, public IPs, hairpin NAT and port forwards. If a device answers on management or service ports from a public IP, treat it as urgent. RTMT for Unified CM is useful here for logs and health data. Look for odd SSH sessions, new admin accounts, CPU or memory spikes, crashes and unplanned restarts. Pull logs off the box so you still have them later.
Patch management is the main defence here. Apply the exact Cisco PSIRT patch for the release you run. Do not guess with a similar image. If Cisco has a fixed build for your release, schedule emergency maintenance and apply it. If your release is not supported with a fix, move to a supported release that includes one. Test the update in a lab or staging cluster before production. Check the build number after the upgrade and run the product health checks. Do a config and compatibility check first; voice services and integration components can break if a patch changes internal APIs. If you cannot patch yet, remove public exposure. Block external access to UC management and service ports at the edge firewall and at the hosting provider level.
Network controls buy time. Block or restrict internet access to SIP, admin and web management interfaces. Allow only known IPs for admin access. Put management interfaces on a separate management VLAN and reach them through a bastion host or VPN. Use tight ACLs on edge devices so only required signalling and media flows cross the perimeter. If an appliance must stay public for call routing, put a session border controller or hosted breakout in front of it so the UC servers are not directly exposed. Do not trust default firewall rules on the appliances to carry the whole load.
After patching, review the period before the fix for signs of compromise. Look for unknown accounts, odd process launches, modified system files and outbound connections to unusual IPs. Collect forensic material: configuration exports, RTMT logs, syslogs and packet captures if you have them. If you find compromise, isolate the node from the network, preserve volatile memory where you can, and rebuild from known good media rather than trying to clean it in place. Rotate administrative credentials and any TLS certificates that might be reused. Keep a timestamped record of what you changed.
Longer term, automate inventory and patch tracking for Cisco UC Manager and related components. Subscribe to vendor PSIRT feeds and KEV alerts so you see this sort of thing early. Keep a short checklist for any public-facing UC service: inventory, exposure check, patch status, backup and restore verification, and rollback plan. Run emergency patch drills so the time between discovery and remediation is not eaten by panic. Periodic configuration audits help too; contractors and automation have a habit of leaving management interfaces open.
Training matters as well. Anyone who touches UC kit should follow a tight change control process. Make it clear who can expose services to the internet and how that gets recorded. Show administrators how to pull RTMT logs, check the build number and apply a patch in a lab. Short runbooks beat long policy documents. Someone needs the authority to declare emergency maintenance when a critical KEV-style vulnerability lands.
Concrete next steps:
- Inventory every UC node and note the exact build and product name, including Cisco UC Manager, Unity Connection and Webex Calling Dedicated Instance.
- If any instance is reachable from the internet, block it at the edge or move it behind VPN or a bastion host.
- Check Cisco’s PSIRT advisory and download the exact fixed build for your release. If no fix exists for your release, plan an urgent migration.
- Pull RTMT and syslog records for the previous 30 days and scan for unusual SSH, admin logins, restarts, new accounts or outbound connections.
- Rotate administrative credentials and TLS certificates after a suspected compromise and after patching.
I run my own homelab with a small voice setup, and I treat UC appliances like any other server that matters. They sit on a management VLAN. SIP only leaves through a session border controller. I test upgrades in a disposable lab before touching production. It keeps exposure down and recovery less painful.
Patching is the fix. Network isolation and quick log review are the stopgaps. Keep a record of what changed and why, because nobody enjoys reconstructing it later from memory.
