Cisco Expressway CVE-2026-76466: unauthenticated RCE to root (CVSS 9.8)

The appliance a lot of organizations put in their DMZ specifically so remote staff can reach internal collaboration without a VPN — Cisco Expressway-E — can be turned into a root shell by someone who never logs in. Cisco published CVE-2026-76466 today, rated CVSS 9.8 critical: an unauthenticated, remote attacker reaching the device's database service can execute arbitrary operating-system commands as root. There is no workaround. The only fix is the upgrade.

Developing story — first published 19:22 CEST (17:22 UTC), October 21, 2026. Updated as the vendor and CISA publish more.

At a glance

CVE	CVE-2026-76466
Product / affected versions	Cisco Expressway-C and Expressway-E (virtual and appliance) configured in a cluster · releases X15.5.3 and earlier · X14 and earlier
Fixed in	X15.5.20 (fixes X15.5.3 and earlier) · X14 and earlier must migrate to a fixed release; also shipped in the October 2026 Expressway Series Security Hardening Release · 2026-10-21
CVSS	9.8 Critical · CVSS 3.1 · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · scored by Cisco PSIRT (NVD not yet independently scored)
Exploited in the wild	No — Cisco PSIRT is not aware of public announcements or malicious use (2026-10-21)
CISA KEV	Not listed (catalog version 2026.10.21)
Public PoC	None public as of 2026-10-21
Official advisory	cisco-sa-vcs-static-cred-hr7EWZ8t

What happened: a static cookie is not a secret

Two weaknesses stack into one unauthenticated path to root, and the Cisco advisory names both. First, the database service trusts persistent cookies. Cisco classifies the bug as CWE-798 — use of hard-coded credentials — because a persistent, predictable cookie is not something an attacker has to steal through a login; it functions as a static credential. Second, when TLS Verify Mode is set to Enabled for clustering, the service fails to actually validate the presented client certificate. The control meant to prove "you are a legitimate cluster peer" is, in effect, off.

Put together, per the advisory: an attacker in possession of the cookies connects to the database service, invokes specific remote-procedure-call (RPC) commands, and the device runs them as root on the underlying OS. No prior authentication, no user interaction, network access only — which is exactly what the PR:N/UI:N in the CVSS vector encodes. The flaw was reported to Cisco by Stefan Aleksic of Jane Street.

"Unauthenticated" is the part defenders should sit with. When the credential is a static artifact baked into how the product talks to itself, the attacker's job is reduced to reaching the port and knowing the shape of the request. That is a much shorter task than cracking a password, and it is the recurring theme in appliance RCE: the dangerous bug is rarely a memory-corruption exotic, it is a trust assumption that was never checked at the boundary.

Who is exposed, and how to check

The advisory scopes this to Cisco Expressway-C and Expressway-E — both the virtual and the hardware appliance forms — running a vulnerable release and configured in a cluster. Cisco Expressway Series here means Expressway Core (Expressway-C) and Expressway Edge (Expressway-E); the same codebase historically shipped as the TelePresence Video Communication Server (VCS), which is why the advisory ID carries the vcs tag.

The reason this one deserves a same-day response is where the box lives. Expressway-E is the traversal node you deliberately place at the internet edge: it is Cisco's VPN-less Mobile and Remote Access (MRA) gateway and the B2B video front door. Root on an internet-facing Expressway-E is not a leaf node — it is the hinge between the public internet and the internal Unified Communications estate, including the path toward Unified CM.

Check your running train from the web UI (Status > System information) or over SSH:

xstatus SystemUnit version

If it reports X15.5.3 or earlier, or any X14 (or older) release, and the deployment is clustered, treat it as affected until patched.

Remediation

1. Am I affected?

Enumerate every Expressway-C and Expressway-E, virtual and physical, and record the software train (xstatus SystemUnit version or Status > System information). Flag any node on X15.5.3-or-earlier or X14-or-earlier that participates in a cluster. Expressway-E nodes with their external interface reachable from the internet are the priority queue — that is where an unauthenticated attacker does not even need a foothold first.

2. Patch — the exact fixed version

There is no workaround; Cisco is explicit that any mitigation is temporary and that upgrading is the fix.

• X15.5.3 and earlier → upgrade to X15.5.20.
• X14 and earlier → there is no fixed release on that train; migrate to a fixed release.
• The same fix is also carried in the October 2026 Cisco Expressway Series Security Hardening Release (advisory cisco-sa-exwy-hardening-FhcqBVcs) — if you are staging that bundle, this CVE is covered.

3. Can't patch this hour? — compensating controls

Cisco offers no supported workaround, so these only narrow the window; they do not close the bug:

• Constrain who can reach the clustering / database-service ports at the firewall. The RPC path this abuses is an internal cluster channel — it should never be reachable from the general internet or from untrusted VLANs. Restrict it to the known cluster peer addresses only.
• Keep the Expressway-E external interface limited to the SIP/H.323/HTTPS traversal services it must expose; nothing about MRA requires the database service to be internet-reachable.
• Prioritize clustered, internet-facing Expressway-E ahead of internal Expressway-C.

4. Hunt for compromise

Cisco has published no indicators of compromise and no exploitation has been observed, so there is no IOC list to match — hunt by behaviour, not by signature, and map it to MITRE ATT&CK:

• T1190 (Exploit Public-Facing Application): unexpected connections to the database-service/clustering port from addresses that are not configured cluster peers.
• T1059 (Command and Scripting Interpreter): processes spawned by the database service that are not part of normal Expressway operation, especially anything running as root.
• T1210 (Exploitation of Remote Services): lateral connections from a compromised Expressway toward Unified CM or internal UC hosts that do not fit the normal MRA/traversal pattern.
• Review authentication, configuration-change and account-creation events on the node and its downstream UC systems around and after the disclosure window.

Because successful exploitation lands as root, the node's own logs cannot be trusted to tell you the truth after the fact — an attacker at that level can rewrite them.

5. Eradicate and verify

If you find evidence of exploitation, patching alone does not undo root access that already happened. Rebuild the affected node from a known-good image at the fixed release rather than upgrading in place, restore configuration from a backup predating the suspected compromise, and rotate every secret the node held — cluster TLS certificates, service and admin credentials, and any trust the node established toward Unified CM. Then re-verify: confirm the fixed version is running and that the database-service RPC path rejects an unauthenticated request, rather than trusting the version string alone.

What is not known yet

• NVD has published the record but not an independent score — the 9.8 is Cisco PSIRT's, mirrored by NVD, which still shows the entry as Received.
• No public proof-of-concept exists as of this writing, and Cisco PSIRT reports no observed exploitation. That can change quickly for an edge appliance with a 9.8.
• Cisco's advisory ties the flaw to the clustered configuration. Whether any non-clustered path is reachable is not spelled out; the safe reading is to patch regardless of cluster state.
• The precise nature of the "persistent cookies" — their predictability or reuse across devices — is not detailed publicly, which is appropriate this early.

We will update this post as CISA, NVD and Cisco publish more.

Finding out before an attacker does

The honest question an Expressway-E operator has tonight is not "how severe is the CVSS" — it is "is my specific box, with my specific cluster and firewall configuration, actually reachable and exploitable from the internet right now?" A severity score cannot answer that. A test can.

That is the job Zero Hunt is built for: an autonomous AI red team that runs on-premise on its own private models, with a human in the loop for anything that touches the device. Its 10-agent swarm fingerprints the exact Expressway train you are running and, rather than replaying a catalog entry, generates a per-target proof-of-concept against that version and that exposure — black-box by default, no credentials assumed, which is precisely the attacker's vantage for an unauthenticated flaw. Every skill it uses is backtested in the AI Gym before it touches a production asset, and every finding is signed at write time (Ed25519, hash-chained) so the evidence that your edge was — or was not — reachable is auditable later, not a screenshot.

When the proof comes back, the AI Remediation Advisor ranks the fix by real exploitability — CISA KEV first, then what the campaign actually proved reachable, then CVSS and EPSS — hands you the exact upgrade (here, X15.5.20) with rollout and rollback notes and the firewall compensating control for the hour you cannot upgrade, and then re-verifies the fix with the same proof that demonstrated the hole. For a deeper walk through continuous, exploitation-proven testing of edge appliances, see our guide to automated penetration testing. Because it all runs on the appliance on-prem, there is no telemetry about your collaboration edge leaving your estate to find out.