Inspur NF5266M5 through firmware 3.21.2 and other Inspur M5-generation servers: An attacker with administrative reach

Impact

An attacker with administrative reach installs their own BMC firmware on Inspur server hardware, and from that point the operator has no reliable way to determine what is running on the controller. The outcomes are the full BMC set - power, console, virtual media, boot control - plus an implant that survives host reimaging and node reprovisioning. Inspur M5 hardware shows up in a lot of Asia-Pacific cloud and HPC estates and in secondhand markets that neoclouds buy from, so this is a real inventory question for anyone assembling capacity opportunistically rather than from a single vendor. The BMC's firmware verification is weak and lacks the checks needed to establish that an image is genuine before flashing it.

Who can reach it

Administrative privilege on the BMC, reachable over the management network. Shared or default BMC credentials on secondhand hardware make this a realistic starting position rather than a theoretical one.

What to do

Firmware update from Inspur - and obtaining it is the problem. Inspur's English security bulletin path returns a hard 404 and the site's homepage carries no PSIRT link, so there is no reachable vendor advisory channel for a non-Chinese-market operator. Given US export and entity-list constraints on Inspur, many operators will also find vendor support unavailable regardless. The practical position: treat Inspur BMC firmware as unverifiable, isolate these BMCs on a management VLAN with no tenant-reachable route, rotate credentials to per-node unique values, and for secondhand M5 hardware assume the BMC may already carry unknown firmware and plan accordingly.

References