The recent discovery by cybersecurity researchers reveals a startling gap in the security posture of modern data centers: over twenty‑four thousand Baseboard Management Controllers (BMCs) are inadvertently exposing authentication material before a user even logs in. These BMCs, which sit on the motherboard of servers and provide out‑of‑band management, are responding to unauthenticated requests with IPMI‑derived password hashes. Because the exposure occurs prior to any authentication step, attackers can harvest these hashes without triggering login failure alerts, opening the door to offline cracking attempts that are far harder to detect. The scale of the exposure—spanning tens of thousands of devices across multiple continents—highlights a systemic blind spot that many organizations have overlooked while focusing on hardening operating systems and cloud workloads.
Baseboard Management Controllers serve as the silent administrators of hardware, controlling power states, firmware flashing, remote console access, and low‑level telemetry. They operate independently of the host OS, meaning that a compromise can survive a complete operating system reinstall or even a hardware swap. This out‑of‑band capability makes BMCs a prized target for adversaries seeking persistent footholds. The protocol most commonly used for this management is the Intelligent Platform Management Interface (IPMI), which has been in use for decades. While newer protocols like Redfish aim to replace IPMI, a large installed base still relies on it, leaving many systems vulnerable to legacy flaws that were thought to be historical footnotes.
The core of the issue lies in CVE‑2013‑4786, a vulnerability rooted in the IPMI v2.0 specification itself. During the authentication exchange, the BMC returns an HMAC‑SHA1 value that incorporates the user’s password and session‑specific data. An unauthenticated attacker who can reach UDP port 623 can request this HMAC and then test password guesses offline, using powerful graphics processing units to try billions of combinations per second. Because the BMC does not require a new network round‑trip for each guess, the attack is stealthy and efficient. Dell’s advisory notes that this is an inherent design characteristic of IPMI v2.0, meaning that no firmware patch can eliminate the leakage; mitigation must come from procedural and network‑level controls.
Lava’s internet‑wide scan conducted on May 6, 2026 identified 36,872 unique hosts exposing IPMI services on UDP port 623. Of those, 24,650—roughly two‑thirds—were found to leak the authentication hash before login. The geographic distribution shows a heavy concentration in the United States (over 14,000 devices), with significant clusters in Germany, China, the Netherlands, and the United Kingdom. This widespread presence indicates that the problem is not confined to a single vendor or region but reflects a global oversight in how management interfaces are provisioned and exposed to the internet.
Further analysis of the leaked hashes demonstrated just how weak many of the underlying passwords are. More than thirty percent of the recovered hashes corresponded to passwords that could be guessed using common wordlists or predictable patterns derived from chassis stickers. In practical tests, Lava’s team cracked HPE iLO factory passwords in under a minute using a modern GPU rig, while Supermicro’s uniquely assigned factory passwords fell in about an hour. These timelines underscore that even passwords intended to be unique or obscure are insufficient when the underlying hash is exposed and attackers can leverage massive parallel cracking power.
The implications are especially grave for today’s AI‑driven bare‑metal environments. Many AI workloads run on dedicated servers that are shared among multiple tenants, and the BMC provides a low‑level conduit that can bypass hypervisor or container isolation. A single compromised BMC could allow an attacker to pivot from one tenant’s workload to another, inject persistent firmware malware, or manipulate telemetry to evade detection. As the AI infrastructure boom accelerates, the value of each exposed server rises, turning what was once a niche hardware‑management issue into a strategic threat to the foundations of AI innovation.
Evidence of active exploitation is already surfacing. Security teams have observed ransomware groups leaving extortion notes directly on the login pages of HPE iLO 4 interfaces, signaling that attackers are not only probing but also attempting to monetize access. Historical incidents such as the iLOBleed rootkit, which targeted iLO servers as early as 2020, demonstrate that threat actors have long recognized the strategic value of BMCs. The combination of readily available cracking tools, persistent malware techniques, and the high value of AI workloads creates a perfect storm that demands immediate attention from data‑center operators.
One reason this vulnerability has persisted is the traditional focus of security teams on the operating system layer and cloud‑native workloads. Management controllers are often viewed as “plumbing”—essential but invisible—leading to insufficient scrutiny during procurement, deployment, and ongoing monitoring. Additionally, many organizations default to using vendor‑supplied passwords or simple variations, assuming that the out‑of‑band network is isolated. In reality, misconfigured firewalls, unnecessary port forwarding, or legacy remote‑access rules frequently expose UDP 623 to the public internet, turning a supposedly internal interface into an open gateway.
Mitigating the risk requires a layered approach that starts at the network perimeter. Blocking UDP port 623 at edge routers or firewalls prevents unauthenticated external reachability altogether. Where remote management is necessary, administrators should restrict access to a dedicated, isolated management VLAN and enforce strict jump‑host or bastion‑host controls. Disabling legacy IPMI 1.5 support and, where possible, moving to Redfish‑only interfaces reduces the attack surface. Rotating factory‑issued passwords during provisioning and enforcing strong, unique credentials—ideally stored in a privileged‑access‑management vault—greatly increases the effort required for offline cracking.
Beyond network controls, continuous monitoring and anomaly detection are essential. Deploying sensors that log and alert on unexpected IPMI traffic, especially from unfamiliar sources, can catch probing attempts early. Integrating BMC logs into a SIEM solution enables correlation with other security events, such as failed login attempts or unusual firmware changes. Regular vulnerability scans that specifically target UDP 623 and verify that no unintended exposure exists should become part of routine hygiene. Additionally, employing hardware‑based security features like signed firmware updates and secure boot for BMCs can help ensure that even if an attacker gains hash access, they cannot easily persist malicious firmware.
Vendors also bear responsibility for improving the security posture of their management controllers. While the IPMI v2.0 specification’s hash leakage cannot be patched, manufacturers can adopt stronger default authentication mechanisms, such as requiring mutual authentication or using challenge‑response protocols that do not reveal password‑derived material. Enhancing default password policies—moving away from predictable chassis‑sticker‑derived passwords and enforcing random, high‑entropy secrets at factory—would dramatically reduce the success rate of offline cracking. Providing clear hardening guides and automated tools for customers to lock down BMC interfaces would further shift the burden from end‑users to suppliers.
In conclusion, the exposure of IPMI password hashes from thousands of BMCs is not merely a theoretical concern; it is an active, exploitable weakness that threatens the integrity of AI data centers and the broader enterprise infrastructure. Organizations must treat BMCs as critical assets, apply network segmentation, enforce strong credential management, and invest in monitoring solutions tailored to out‑of‑band management. By combining immediate mitigations with longer‑term vendor engagement and procedural improvements, security teams can close this dangerous gap and ensure that the foundations of their compute environments remain resilient against evolving threats.