Cisco has released a fix for a critical vulnerability in clustered Expressway deployments that could allow a remote attacker to execute operating-system commands with root privileges. The issue, tracked as CVE-2026-76466, carries a CVSS score of 9.8 and affects both Expressway Core and Expressway Edge when vulnerable software is operating as part of a cluster.

The potential impact is severe because Expressway commonly supports communications that cross an organization’s network boundary. Root-level command execution would give a successful attacker control over the underlying appliance, creating opportunities to alter its configuration, establish persistence, observe traffic, or use the system as a foothold for further intrusion.

How the cluster weakness can be exploited

The vulnerability resides in the product’s database service and concerns its handling of persistent cookies. Cisco also found that client certificates are not validated correctly when clustering has TLS Verify Mode enabled. Consequently, administrators may believe certificate verification is enforcing a trust boundary that the affected implementation does not actually provide.

An attacker needs network access to the vulnerable database service and possession of the required cookies. With those conditions met, the attacker could connect to the service and invoke specially selected remote procedure calls. Those calls can reach operating-system command execution with root authority.

The cookie requirement is an important qualification. Cisco describes the attacker as unauthenticated, but the advisory does not explain how the necessary cookies might be obtained. That means the flaw should not be interpreted as instant compromise of every reachable appliance. It does, however, leave affected clusters facing an unusually high-impact outcome if an attacker satisfies the prerequisites.

Affected versions and the available fix

Cisco says Expressway releases 15.5.3 and earlier are affected. Release 15.5.20 is the first version containing the correction. Organizations still running version 14 or an older train must migrate to an appropriate fixed release rather than wait for a patch on that branch.

No workaround addresses the underlying weakness. The update is included in Cisco’s broader October 2026 Expressway security-hardening release, which contains additional defenses identified during an internal review. Administrators should distinguish the cluster-specific CVE from the wider hardening work: CVE-2026-76466 requires clustering, while other items in the release may apply regardless of configuration.

What administrators should do now

Security teams should first build an accurate inventory of Expressway-C and Expressway-E instances, including virtual machines and hardware appliances. They should then confirm both the installed release and whether clustering is enabled. Version data alone is not enough to determine exposure to this particular issue.

• Upgrade affected clusters to Expressway 15.5.20 or a later supported release.
• Restrict database and management interfaces to trusted administration networks.
• Review authentication material and appliance logs for unexplained database connections or RPC activity.
• Use Cisco’s compatibility guidance before upgrading interconnected communications components.

Cisco credited Stefan Aleksic of Jane Street with reporting the problem. At the time of disclosure, Cisco’s incident-response team said it was not aware of public exploitation or announcements demonstrating attacks. That is reassuring but should not delay remediation: disclosure gives researchers and threat actors a roadmap, while the absence of a workaround leaves patching as the only complete remedy.

Organizations should also treat an exposed Expressway device as a high-value edge asset. If suspicious activity is found, responders should investigate beyond the appliance itself, rotate relevant secrets, validate neighboring systems, and examine whether the device was used to reach internal services. A timely upgrade, tightly restricted access, and focused log review provide the strongest near-term response.

After installation, teams should confirm the running version on every cluster member and test normal call-routing and federation functions. Recording that evidence in the change ticket helps distinguish a completed deployment from an update that was staged but never activated.