AMI MegaRAC SPx 12 (BMC default TLS certificate): The BMC ships with a hard-coded default TLS certificate, so HTTPS

Impact

The BMC ships with a hard-coded default TLS certificate, so HTTPS to the management interface can be transparently intercepted by anyone holding the extracted key - which is everyone, since it is identical across all devices built from that firmware. The operator loses exactly what they thought they were buying with HTTPS: BMC admin passwords, Redfish tokens and KVM traffic are readable to an attacker who can sit in the path. Because the same certificate is on every node, a single extraction compromises the whole management plane.

Who can reach it

Requires a man-in-the-middle position on the management network - a compromised jump host, a rogue device on the management VLAN, or control of a switch or DHCP server on that segment. No credentials needed. Disclosed by Nozomi Labs against a Lanner IAC-AST2500A platform; AMI's own advisory confirms the affected code is part of MegaRAC SPx, so the exposure is not limited to that one vendor's box.

What to do

Firmware flash to SPx_12-update-3.00 or later (AMI states SPx_13 is not affected), but flashing alone does not fix a node whose certificate is already installed. The operative fix is config-only and can be done today across the fleet without a reboot: generate a unique certificate per BMC from your own internal CA and push it over Redfish, then have your management tooling actually pin or verify it rather than skipping certificate validation - which is the default in most homegrown BMC scrapers and is the reason this bug stays exploitable.

References