Database/Control plane, storage & DevOps
SPI flash descriptor region configuration on a wide range of Supermicro boards: Any software running with sufficient
Impact
Any software running with sufficient privilege on the host operating system can rewrite the platform firmware. That is a UEFI/BIOS implant written from userland-reachable code - it survives disk wipes, OS reinstalls, and node reprovisioning, and it is invisible to every host-based security tool the operator runs. On bare-metal GPU rental this is the canonical tenant-persistence attack: a tenant with root on their leased node writes firmware, releases the node, and retains a foothold on hardware that is subsequently handed to someone else. X11S, X10, X9, X8SI, K1SP, C9X299, C7, B1, A2 and A1 families. The descriptor is what tells the chipset which flash regions the host CPU may write; Supermicro shipped it misconfigured so the OS could write firmware.
Who can reach it
Host-side privileged code execution - root on Linux or an equivalent. No network position on the management VLAN is required at all, which makes it the mirror image of the BMC bugs in this list: the threat comes from inside the node, from whoever you rented it to.
What to do
BIOS/firmware flash with a Supermicro image that ships a locked descriptor region, per board family. Verification matters more than the flash here: after updating, confirm the descriptor is actually locked - Intel's chipsec common.bios_wp and descriptor checks will tell you - because the fix is a configuration inside the firmware image and it is easy to assume it landed when it did not. For a bare-metal rental fleet, add a descriptor/flash-lock check to the node turnup and node return pipeline rather than treating it as a one-time patch.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.