Decades-Old IPMI Vulnerability Exposes Over 24,000 BMC Interfaces Online

More than 24,000 internet-accessible server management processors are currently disclosing password-derived authentication hashes to unauthenticated remote users. The exposures stem from CVE-2013-4786, a fundamental flaw in the IPMI 2.0 specification introduced back in 2004. Because these Baseboard Management Controllers (BMCs) sit at the lowest level of data center hardware, exposed management interfaces allow attackers to harvest administrative credentials offline and take total control of host hardware.

Recent scanning data from cybersecurity firm Lava highlights that thousands of critical management planes remain directly exposed to the public internet, leaving data center infrastructure vulnerable to silent, highly privileged footholds.

How the IPMI 2.0 Pre-Auth Hash Leak Works

Baseboard Management Controllers are dedicated microcontrollers embedded on server motherboards. They operate out-of-band, remaining powered on and reachable as long as the server has standby power, completely independent of the main CPU, operating system, or hypervisor status. Administrators rely on BMCs to monitor hardware health, power-cycle frozen servers, update system firmware, and mount virtual media over the network. To facilitate this, BMCs expose protocols like the Intelligent Platform Management Interface (IPMI), the modern HTTPS-based Redfish API, and web administrative portals.

The vulnerability, tracked as CVE-2013-4786, resides in the Remote Authenticated Key Exchange Protocol (RAKP) defined in the IPMI 2.0 specification. During the initial handshake over UDP port 623, an unauthenticated client sends a RAKP Message 1 requesting access for a specific username. The BMC responds with a RAKP Message 2, which includes an HMAC-SHA1 authentication code generated using the requested user’s password and session parameters.

Crucially, the BMC calculates and transmits this HMAC response before authenticating the requester. Any unauthenticated attacker with network access to UDP port 623 can request a RAKP Message 2 for any existing account on the device. Once received, the attacker can take the HMAC off the wire and feed it into modern, GPU-accelerated password cracking utilities like Hashcat or John the Ripper. Because the attack occurs entirely offline, the target BMC never logs repeated failed login attempts, rendering traditional online brute-force protections and account lockouts completely useless.

The Extent of Public Exposure

New findings from security firm Lava underscore how widespread this architectural weakness remains across enterprise and cloud hardware:

• 37,000 total interfaces: Roughly 37,000 internet-exposed server-management interfaces are reachable over the IPMI protocol on the public internet.
• 24,000+ vulnerable interfaces: Over 24,000 of those publicly exposed endpoints disclose password-derived authentication hashes before login due to CVE-2013-4786.
• 6,240 default/empty setups: A total of 6,240 exposed hosts were found accepting empty usernames paired with weak or default passwords.
• 2,340 predictable admin accounts: At least 2,340 host interfaces had active administrative accounts (such as Admin or root) using passwords frequently listed in public wordlists or relying on predictable factory-issued templates.

When combined with automated internet scanning and high-throughput offline hash cracking, an attacker can reliably go from an exposed port to cleartext administrative credentials in a short time frame.

The Blast Radius of a Compromised BMC

A compromised BMC represents one of the worst-case security boundaries breaches in a data center environment. In most OEM implementations (including systems from Supermicro, Dell, HPE, and Lenovo), the BMC shares a single unified account database across all available management protocols. A credential harvested and cracked via IPMI 2.0 routinely unlocks access to the web console, Redfish REST API, and virtual KVM console.

Once inside the management plane, an attacker gains capabilities that completely bypass traditional host-based security tools like EDR agents, host firewalls, and audit logging:

1. Host Tampering & Interception: An attacker can remotely map a malicious ISO image via virtual media and force a reboot, allowing them to boot the underlying physical server into a custom OS environment to scrape local storage drives or install persistent kernel rootkits.
2. Firmware Integrity Compromise: Attackers can flash malicious option ROMs, UEFI firmware, or modified BMC images, establishing persistence that survives host re-imaging, drive replacements, and OS upgrades.
3. Data Center Pivoting: Because BMCs are frequently connected to internal management VLANs that span entire racks or data halls, a single exposed BMC interface serves as a low-noise operational bridge directly into the internal core network.

Because endpoint monitoring software operates inside the host operating system, it has zero visibility into actions taken at the BMC level. Hardware-level reboots, virtual media attachments, and firmware flashes happen entirely out-of-band.

Securing Data Center Management Planes

Remediating CVE-2013-4786 cannot be accomplished through a simple vendor software patch because the hash-exposure flaw is part of the official IPMI 2.0 protocol specification. While newer BMC standards rely on Redfish over HTTPS, legacy IPMI implementations remain widely supported for backward compatibility. Securing these management interfaces requires strict network isolated controls and credential management:

• Eliminate Internet Exposure: Never expose IPMI (UDP port 623) or BMC web portals directly to the internet. Management interfaces must reside on isolated, non-routable Out-of-Band (OOB) VLANs accessible exclusively via jump boxes, zero-trust network access (ZTNA), or encrypted administrative VPNs.
• Disable IPMI 2.0: If hardware support permits, disable IPMI 2.0 services across all BMC interfaces entirely, transitioning all out-of-band management operations to Redfish over TLS with strict authentication controls.
• Rotate Default Credentials Immediately: Force unique, complex passwords (minimum 16+ characters) across all pre-configured administrative accounts (admin, root, vendor defaults) to make offline GPU cracking computationally infeasible if a hash is intercepted.
• Implement Network Access Control Lists (ACLs): Restrict hardware-level management ports at the switch level so that UDP port 623 traffic is explicitly dropped except when originating from designated management subnets.