BMC firmware for Intel Server Boards S2600WF / S2600ST / S2600BP before 02.01.0017 and M50CYP, and OpenBMC firmware

Impact

Improper access control in the BMC firmware on Intel's own server boards, with companion out-of-bounds read and uncaught-exception issues in the OpenBMC builds Intel ships for current Eagle Stream and Birch Stream platforms. BMC compromise is node ownership below the OS: virtual media, power control, KVM, and the firmware update path into BIOS and ME. It survives host reimage by construction and carries into the next tenant, and mass BMC access is a hall-level power-off capability. The OpenBMC entries matter because many neocloud whitebox designs run Intel's OpenBMC tree rather than a commercial BMC stack, and those builds are updated far less often.

Who can reach it

Access to the BMC - network access on the out-of-band management path for the network-facing issues, privileged local access for the information-disclosure path, and the host KCS interface where it has not been disabled.

What to do

BMC firmware update to 02.01.0017 or later on the S2600 boards, and to the fixed OpenBMC branch (egs-1.15-0 / bhs-0.27 or later) on the current platforms - from Intel or from the ODM that built the board (Quanta, Wiwynn, Supermicro, Inventec). BMC updates do not need a host reboot, so this is cheap to roll relative to BIOS work. If you run whitebox nodes on Intel's OpenBMC, you own the update cadence yourself - there is no OEM pushing it to you, and that is the real finding here. Keep the BMC network isolated, credentials unique per node, and KCS disabled.

References