BMC Vulnerability Data Centre 2026: UK Audit Urgently Needed

An old CVE, a live crisis for the management plane

The vulnerability, tracked as CVE-2013-4786, lives in the IPMI 2.0 authentication protocol used by Baseboard Management Controllers, according to data centre security firm Lava. IPMI is a 22-year-old out-of-band management standard, and the flaw allows unauthenticated attackers to pull password-derived authentication hashes straight from a BMC before login even completes. Dell's own support guidance describes this as an inherent problem in the specification itself, with no patch available.

That distinction matters for UK buyers. This isn't a missed update sitting in a backlog. It's a structural weakness that persists unless organisations actively remove exposure, rotate credentials, and segment the network the BMC sits on.

What the scan actually found

Lava's researchers located 36,872 internet-reachable BMCs still exposing IPMI. Of those, 24,650 — 66% — disclosed authentication hashes on request. When tested against common wordlists, more than 30% of those hashes matched reused, factory-set, or predictably formatted passwords, often on the first attempt. Separately, nearly 17% of exposed BMCs accepted an empty username paired with a weak password.

Supermicro and HPE servers were among the most affected by volume, though Supermicro's own share of matched weak passwords was notably lower. That's because Supermicro moved in 2019 to unique, factory-issued 10-character passwords printed on chassis labels, rather than a shared default. Lava reported its findings to Supermicro, which said it would review default password policy for future hardware, and Lava has confirmed the specific exposure it flagged has since been addressed.

Why security teams keep missing this layer

Security consultant David Shipley of Beauceron Security frames the problem as an organisational blind spot rather than a technical one. BMCs sit in what he calls a "weird in-between space between teams" — not fully networking's responsibility, not fully the system administrators', because the controller operates before the OS even boots.

Michael Katchinskiy, Lava's head of security research, put the core issue plainly: BMCs give attackers "control beneath the host while remaining largely invisible to the tools designed to protect it." Endpoint detection, kernel monitoring and container security tooling all sit above this layer and simply cannot see it. Anyone benchmarking iDRAC, iLO, and xClarity management platforms should treat this visibility gap as a procurement criterion, not an afterthought.

Persistence is the real danger, not just access

A compromised BMC survives the incident-response playbook most teams reach for first. Reimaging the OS, replacing a disk, or rebuilding a container doesn't touch firmware-level changes made through the controller. Attackers can power devices off, reflash firmware, or simply sit quietly and use the BMC as a durable foothold to probe for further weaknesses elsewhere on the estate.

The risk compounds in shared and multi-tenant environments. Neocloud and GPU cloud platforms often run thousands of accelerators across a single shared out-of-band management network, with common orchestration, credential stores and admin tooling spanning multiple customers. A single weak BMC credential can therefore become a route into infrastructure well beyond the server it was found on — a scenario UK buyers evaluating AI or high-density hosting contracts should be asking providers about directly.

What a UK infrastructure audit should check first

Vendor guidance converges on the same starting point: IPMI and Redfish interfaces should never be reachable from the public internet. NVIDIA's BMC security guidance calls for isolated management networks, IBM recommends keeping IPMI disabled by default in favour of Redfish APIs, and Dell's iDRAC documentation stresses that IPMI traffic should be segmented because the protocol is inherently stateless.

Practical steps for an internal or third-party audit include:

• •Replace every factory-issued or default BMC password immediately, with strong, unique credentials per host
• •Move all IPMI and Redfish interfaces onto a dedicated private management network reachable only via VPN or jump box
• •Apply network access controls limiting BMC reachability to named, approved administrators
• •Disable legacy protocol versions, anonymous accounts, and any tokenless authentication path
• •Log and monitor BMC login attempts and firmware changes separately from production workload monitoring

Building this into a wider security programme

This isn't a one-off scan-and-patch exercise, because there is no patch for the underlying specification flaw. It needs to sit inside ongoing zero trust and managed detection & response programmes that explicitly extend visibility below the OS layer. Teams running estates built on HPE servers or Supermicro servers should treat BMC credential rotation and network segmentation as a recurring line item, not a project that closes once complete.