AMI MegaRAC SPx 12 / SPx 13 (BMC network service): Unauthenticated code execution inside the BMC, reached

Impact

Unauthenticated code execution inside the BMC, reached with a crafted packet and nothing else. The attacker lands below the hypervisor on a processor that stays powered whether or not the node is booted, and from there owns the node's power state, its console, its virtual media and its BIOS flash. On a GPU fleet this is the classic rack-wide implant: reimaging the tenant OS, replacing the NVMe, or rebuilding the node from the provisioning system does not remove it. AMI rates the scope as changed, meaning the BMC compromise is expected to reach beyond the BMC into the host.

Who can reach it

Any host on the same L2 segment as the BMC management interface - no credentials, no user interaction, low attack complexity. In practice that means any compromised node, switch, PDU, out-of-band jump box or IPMI-speaking tool that shares the management VLAN. If BMCs are flat-VLANed across a hall (a common shortcut in leased colo and neocloud builds), one foothold reaches every BMC in the hall.

What to do

BMC firmware flash to MegaRAC SPx_12.7 / SPx_13.6 or later - out-of-band, per node, with real bricking risk if power or the transfer is interrupted mid-write. You cannot take AMI's build directly: your ODM (Supermicro, Quanta, Gigabyte, Wiwynn, ASRock Rack, Inventec) must rebase and requalify, and that lag has historically run six months to over a year, longer on white-box SKUs whose vendor has stopped shipping BMC images. The host generally stays up through the flash but KVM/vMedia sessions drop and the BMC reboots. Until the image exists, the only real control is network: put BMCs on an isolated management VLAN with no route from tenant, storage or corporate networks, and reach them only through a bastion.

References