Expressway Fixes Need More Than One Version Check
Cisco Expressway’s October security releases cover several different boundaries: access to a clustered database service, weaknesses across clustered and standalone systems, information exposed during provisioning, and PHP embedded in the product. A team can complete one of those checks and still have work left. Cisco’s PHP matrix has also moved on since the initial release, so an older copy of the product table is insufficient.
The database flaw has a specific cluster prerequisite
Cisco’s 21 October database-service advisory identifies CVE-2026-76466, rated critical at 9.8. The affected set is Expressway Core and Edge, known as Expressway-C and Expressway-E, running a vulnerable release in a cluster. Both virtual installations and physical appliances are included.
An attacker needs network access to the database service and possession of persistent cookies. Invoking particular remote procedure calls can then execute operating-system commands as root. Cisco also says client certificates are not validated when the clustering TLS Verify Mode is enabled. An enabled setting therefore does not demonstrate that this validation is actually enforced on an affected release. The unauthenticated classification must be read alongside the cookie-possession prerequisite.
The database table lists X15.5.20 as the first correction for its X15.5.3-and-earlier row. X14 and earlier must migrate to a fixed release. Cisco reports no workaround that resolves the vulnerability. Network restrictions may reduce exposure as part of an authorised response, but they do not replace the listed software correction or establish that earlier access did not occur.
Standalone systems still need the hardening review
The broader Expressway hardening advisory has a different configuration scope. It includes virtual and appliance Core and Edge systems regardless of configuration. A standalone deployment that falls outside the clustered database finding cannot use that exclusion to dismiss the wider release.
Cisco groups internally discovered findings into eight weakness classes: out-of-bounds writes, reachable assertions, null-pointer dereferences, uncaught exceptions, code injection, incorrect permissions, link following and insecure temporary files. A group’s published score represents its most serious underlying finding. Eight group identifiers are not evidence of exactly eight individual bugs, nor do they establish one shared attack path. This bulletin uses the same X15.5.20 correction row and migration direction as the database notice, with no workaround. Its 27 October revision corrected the description for the write-error class.
The provisioning disclosure has an earlier threshold
A separate information-disclosure advisory covers CVE-2026-76435. Insufficient authorisation of HTTP requests during Mobile and Remote Access provisioning can let an unauthenticated remote attacker obtain sensitive information using a crafted URL request. Cisco’s publication-time scope includes both Core and Edge, virtual and appliance versions, regardless of configuration.
That notice’s publication-time table identifies X15.5.3 as the correction for X15.5.2 and earlier, and directs X14 and earlier to migrate. It points readers to the linked bug record for the most current detail and reports no workaround. Passing this earlier threshold does not establish that the database and hardening corrections above are installed.
The current PHP matrix adds a separate product check
Cisco’s PHP bulletin is now final version 1.10, updated on 30 October at 19:24 GMT. It concerns CVE-2026-109618 and CVE-2026-109619. The original PHP record for the first issue describes unsafe request cleanup after memory-allocation failure. The second record concerns global state retaining references to freed request memory. Both can lead to remote code execution.
The current Cisco table lists 15.5.21 for Expressway Series and Expressway Select Series. It also marks both rows as having a product-specific workaround, with details in the linked Cisco bug. Do not carry the other Expressway notices’ no-workaround statement across to this PHP bulletin, or invent a generic workaround from that marker. Confirm the applicable vendor procedure and corrected product build. An upstream PHP version or an Expressway database-fix record alone is insufficient evidence.
Cisco’s PHP exploitation statement says PSIRT was not aware of malicious use against a Cisco product. That is a dated vendor observation. The separately reported PHP2Shell attacks against PAN-OS concern another vendor’s appliances; they do not establish exploitation of Expressway. Equally, Cisco’s statement is not proof that an exposed deployment has never been accessed.
Close the change against the running service
Keep the exact product, Core or Edge role, cluster state, installed build and applicable advisory rows together in the change record. Select a supported upgrade that covers the relevant notices and the deployment’s compatibility requirements. After an authorised change, verify the running build on every relevant node and test normal communications and failover. A download, an upgrade booking or one healthy node is not confirmation that the deployment has completed the work.
Certificate trust is a separate operational check. For customer-managed SIP connections to Webex Meetings, the planned 2 November trust change can require attention to the certificate chain presented by Expressway-E. A software upgrade record does not, by itself, verify that chain. Keep the software remediation and the applicable certificate-and-service tests visible as distinct evidence.
