AMI MegaRAC SPx 12 / SPx 13 (BMC TLS certificate generation): Malformed input to the BMC's certificate-generation

CVSS 4.9CVE-2021-44769Firmware, BMC & network fabricAMI-SA-2022001Nozomi Labs BMC firmware researchcurated

Impact

Malformed input to the BMC's certificate-generation function permanently wedges the controller, and the only documented recovery is a factory reset. On a GPU fleet that is worse than a normal DoS: you lose out-of-band power control, console and virtual media on the affected nodes, and getting them back means an on-site factory reset that also wipes your BMC configuration - accounts, certificates, network settings, alert destinations - so every affected node has to be re-provisioned by hand. A malicious insider or a compromised management account can do this across a rack in minutes and cost you days of remote-hands work.

Who can reach it

Network access to the BMC with high privileges - an administrative BMC account. Because BMC admin credentials are so often cloned across a fleet by the provisioning system, one leaked credential scales this to every node that shares it.

What to do

Firmware flash to SPx_12-update-5.00 / SPx_13-update-3.00 or later, out-of-band per node, ODM-gated. Config-only risk reduction: unique per-node BMC admin credentials so one leak cannot sweep the fleet, and - critically - keep an exported, version-controlled copy of every BMC's configuration so that if you do have to factory-reset, restoring is automated rather than a per-node manual rebuild.

References

https://9443417.fs1.hubspotusercontent-na1.net/hubfs/9443417/Security%20Advisories/AMI-SA-2022001.pdf https://www.nozominetworks.com/labs/vulnerability-advisories/cve-2021-44769/https://nvd.nist.gov/vuln/detail/CVE-2021-44769

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.