Supermicro BMC firmware web/management service (X11/X12/X13/H12/H13/B12/B13, CMM6): An attacker who never authenticates

Impact

An attacker who never authenticates gets code execution inside the BMC's own firmware OS. On a GPU fleet that means out-of-band power control over every affected node, the ability to mount an attacker-supplied ISO as virtual media and reboot a node into it, KVM access to whatever a tenant has on the console, and a persistent implant living beneath the hypervisor and the host OS that survives every reimage, every OS patch and every tenant handoff. Because the BMC also drives the CMM6 in blade chassis, a single compromised management module gives leverage over an entire enclosure rather than one node. H13, B12 and B13 motherboards plus CMM6 blade chassis management modules - i.e. essentially the whole current Supermicro server line including the GPU chassis and SuperBlade enclosures.

Who can reach it

Anything that can open a TCP connection to the BMC's management interface, with no credentials at all. In practice that is anyone with a route to the out-of-band management VLAN - a jump host, a misconfigured L3 leaf, a compromised DCIM or monitoring box, or a BMC that ended up with a public address. No host-side foothold and no tenant workload access is required.

What to do

Firmware flash, per node, out of band. Supermicro shipped fixed BMC images in its July 2024 BMC/IPMI advisory batch, but the fixed version differs per motherboard SKU, so an operator with a mixed X11/X12/X13 fleet has to build a board-to-image matrix before flashing anything. Budget a BMC reboot per node - the host stays up during a BMC flash on most Supermicro boards but a failed flash can leave the BMC unresponsive and requires a physical recovery, so stage it rack by rack. Until every node is flashed, the only mitigation that actually holds is hard network isolation: BMCs on a dedicated VLAN with no route from tenant networks and an explicit allowlist for the handful of management hosts that need them.

References