Redfish API implementation on Cisco UCS B-Series, UCS Managed C-Series and UCS X-Series servers: An administrator-level

Impact

An administrator-level Redfish user escapes the API's intended command surface and executes commands on the underlying management controller. The operator-relevant point is the boundary being crossed: Redfish administrative privilege is supposed to mean 'can configure the server', not 'can run code on the controller', and that distinction is what lets an operator delegate Redfish admin to automation without handing over the box. When it collapses, every service account your provisioning system holds becomes a shell on every BMC it manages. Command injection reachable through the Redfish interface by a user who already holds administrative privileges in the management software.

Who can reach it

An authenticated remote user with administrative privileges on the UCS management software, reaching the Redfish API. In practice this is your automation's own credentials - Terraform providers, Ansible modules and inventory collectors all hold Redfish admin, and any compromise of the automation host inherits it.

What to do

Firmware/software update to the fixed UCS release per Cisco's advisory; this is a controller firmware update, so plan a per-chassis maintenance window rather than a rolling config push. The durable lesson is architectural: stop treating Redfish administrative accounts as a safe delegation boundary. Scope automation credentials to the narrowest Redfish role that works, keep them out of shared secret stores that tenant-facing systems can read, and log Redfish administrative calls centrally so an anomalous command sequence is visible.

References