CVE-2026-76466 (CVSS 9.8) gives unauthenticated root on clustered Expressway-C and -E. There is no workaround: upgrade to X15.5.20; X14 must migrate.
Cisco has disclosed CVE-2026-76466, a critical (CVSS 9.8) remote code execution flaw in Expressway-C and Expressway-E, the collaboration edge gateways. An unauthenticated attacker with network access can run arbitrary operating system commands as root. Cisco lists no workaround. The only remedy is to upgrade to X15.5.20, and customers on X14 and earlier must migrate to a fixed release because no X14 fix exists. As of the advisory, Cisco PSIRT says it is not aware of public announcements or malicious use.
Who is affected
The advisory (cisco-sa-vcs-static-cred-hr7EWZ8t, published 21 October 2026) covers Cisco Expressway-C (Core) and Expressway-E (Edge), both virtual and appliance versions. A system is vulnerable only if it runs an affected release and is configured in a cluster. Standalone nodes are not described as affected.
The CVE record lists a wide range of releases as affected, from the X8 branches through X12.5, X12.6, X12.7, X14.0, X14.2, X14.3, X15.0, X15.2, X15.3, X15.4.0 and X15.5.0 through X15.5.3. Cisco's fix guidance is simpler: X15.5.3 and earlier are first fixed in X15.5.20, and X14 and earlier have no fixed release in their own branch.
What the flaw is
The weakness is classed as CWE-798, use of hard-coded credentials, and sits in the Expressway database service. Cisco describes two causes:
- Persistent cookies. An attacker who holds these cookies can connect to the database service and invoke specific RPC commands.
- Weak client certificate validation. When the clustering TLS Verify Mode is set to Enabled, client certificates are not properly validated.
The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network reachable, low complexity, no privileges, no user interaction. The cluster requirement is the main limiter on exposure. Cisco's text does not say which network interface or port carries the database service, so defenders should not assume it is unreachable from the internet-facing Expressway-E side until they have checked.
Cisco credits Stefan Aleksic of Jane Street with the report. The bug ID is CSCww27732.
A second, separate Expressway advisory
On the same day Cisco published an Expressway hardening advisory (cisco-sa-exwy-hardening-FhcqBVcs) covering CVE-2026-76490 through CVE-2026-76497, rated High, with a top CVSS of 8.6. Cisco says these were found internally using existing testing processes and frontier AI models, are not known to be exploited, and apply to Expressway-C and -E regardless of configuration. The fixed release is again X15.5.20. As fetched, that advisory's text does not mention CVE-2026-76466, so treat them as distinct issues that one upgrade happens to address.
Do not confuse this with the PHP2Shell problem. ThreatFrontier covered that separately in PHP2Shell: Two Pre-Auth PHP RCEs Are Patched, but PAN-OS, Panorama and Cisco Expressway Still Wait. heise reports Cisco has no fix date for Expressway on that issue and that version 15.5.21 is expected to be unaffected, with the PHP flaws described as under attack. Moving to X15.5.20 resolves CVE-2026-76466 but, on heise's reporting, does not close PHP2Shell, so plan for a further upgrade to 15.5.21 or later.
Match your release to the move: X15.5.20 fixes CVE-2026-76466, 15.5.21 or later is the target for PHP2Shell, and X14 has to migrate.
What defenders should do
- Find clustered Expressway nodes. Inventory every Expressway-C and -E, note the release and whether clustering is configured. Unclustered nodes are outside the stated condition for this CVE, but still need the hardening fixes.
- Upgrade to X15.5.20 or later. There is no mitigation. Because Cisco says X14 and earlier will not be fixed, schedule the migration now and treat these systems as unpatched until it is done.
- Restrict network reach in the meantime. This is general hardening, not a Cisco-documented workaround: limit access to cluster peer traffic to the other cluster members only, especially on Expressway-E nodes in the DMZ.
- Check TLS Verify Mode. Cisco names client certificate validation under clustering TLS Verify Mode as part of the problem, so confirm the setting in your cluster configuration after upgrading.
- Hunt for signs of compromise. Review logs for unexpected connections to the cluster database service from hosts that are not cluster peers. Cisco has published no indicators of compromise in the advisory.
- Watch for exploitation. Cisco reports none so far; recheck the advisory for revisions, since this one is at version 1.0.