Lenovo XClarity Controller (XCC) - IPMI command handler: A specially crafted IPMI command gives an authenticated XCC

Impact

A specially crafted IPMI command gives an authenticated XCC user arbitrary code execution on the controller. Code execution on the BMC is the terminal outcome for a node: the attacker holds power control, Virtual Media, console and the firmware write path, and can plant an implant that lives below the hypervisor and survives every reimage. It is one of a cluster of XCC command-injection issues Lenovo fixed across 2024 reachable through IPMI, the SSH captive shell and file upload - the IPMI path is the one that matters most because IPMI is so often left enabled for legacy automation.

Who can reach it

An authenticated XCC user with elevated privileges sending IPMI commands - so the exposure is your administrative BMC credentials plus anything on the management VLAN that can reach the IPMI service. Compromise of an automation host that holds XCC admin creds is the realistic path.

What to do

Flash XCC to the per-model version in LEN-156781 - out-of-band, per-node, no host reboot and no drain. The high-value config-only mitigation is to disable IPMI over LAN on XCC where your tooling has moved to Redfish, which removes this entire command surface rather than fixing one handler in it. Budget for migrating any remaining ipmitool-based automation first.

References