Cisco Finesse SSRF disclosed with no fix due until early 2027

An unauthenticated SSRF in the Finesse management interface

CVE-2026-20362 is a server-side request forgery (SSRF) flaw in the web-based management interface of Cisco Finesse, according to a dev.to write-up summarizing Cisco's advisory. The vulnerability is unauthenticated, carries a CVSS v3 base score of 7.2, and its vector marks scope as changed, meaning the impact can extend beyond the vulnerable component itself.

Cisco traces the issue to improper input validation for certain HTTP requests. An attacker who sends a crafted request can make the Finesse server initiate network requests on the attacker's behalf, and the advisory indicates this could expose limited sensitive details about services tied to the affected device.

Finesse is the agent desktop for Cisco's contact center platforms, and it is also bundled inside Packaged CCE, Unified CCE and Unified CCX. Two details sharpen the situation: the flaw is present regardless of how the device is configured, and a public announcement about it already exists. In other words, the details are out while the fix is not.

Fixes land in early 2027

The calendar is the story. The fixed releases listed in the advisory, as reported by the dev.to write-up:

• Cisco Finesse 15.0(1) SU3 — February 2027
• Packaged CCE and Unified CCE 15.0(1)ES202701 — January 2027
• Unified CCX 15.0(1) SU2 — February 2027

Deployments running Finesse 12.6 or earlier have no fixed release to wait for at all; Cisco's guidance for them is migration. Cisco also states that there are no workarounds. That combination — public disclosure, no patch until 2027, no workaround — leaves administrators with compensating controls as their only lever.

What operators can do now

The dev.to write-up sketches a mitigation posture for the interim:

• Keep the Finesse web interface off untrusted networks, and treat who can reach the management interface as the primary control.
• Watch outbound traffic from Finesse hosts for destinations the contact center has no legitimate reason to contact. SSRF activity tends to show up as outbound connections to unexpected places, so egress monitoring can catch exploitation attempts.
• Document the accepted risk formally, with a named owner and a scheduled review date, so the exposure does not quietly outlive the wait.

Cisco reports no known malicious use of the flaw so far, according to the write-up. One caveat it also raises: the fix dates come from the vendor advisory, and release schedules change, so administrators should re-verify them before building plans around them.

Why it matters

The default answer to most vulnerability disclosures — apply the vendor update — simply does not apply here. Enterprises running affected contact center builds face a publicly documented, unauthenticated flaw in a management interface, with a fix that is months away and no vendor-endorsed workaround.

The situation is also a stress test for patching programs. Teams that measure security posture by patch compliance have nothing to patch; the meaningful controls are architectural, such as network segmentation around the management interface, and operational, such as egress monitoring and formal risk acceptance. Contact centers rarely tolerate downtime, which makes the eventual migration path for 12.6-and-earlier deployments its own project.

Finally, the case is a reminder that disclosure timelines and vendor release trains do not always align. When they diverge this far, the gap has to be covered by the defender — and here that gap is measured in months, not days.