Summary
- Lava’s 6 May scan measured 36,872 unique public IPMI endpoints; that is a count of addresses at one point in time, not of data centres, servers or customers.
- Of those endpoints, 24,650, or 66.9%, returned at least one password-derived RAKP response before client authentication.
- The researchers matched a weak-password candidate for 6,240 empty-username responses and a common-password candidate for 2,340 named-account responses.
- They recovered the documented factory-format password for two modern Supermicro systems at an unnamed GPU provider, did not authenticate and say the provider later fixed the exposure.
- CVE-2013-4786 has described the underlying IPMI 2.0 RAKP weakness since 2013; the new evidence is the 2026 measurement of public deployment.
- The immediate control is architectural: remove IPMI from the public internet, restrict UDP 623, isolate the management network, rotate credentials and monitor the plane separately.
Three denominators prevent one misleading headline
The first denominator is reachability. Lava found 36,872 unique public IPMI endpoints on 6 May. A public IP address can change hands, front more than one physical system or disappear after the scan. It does not reveal how many data-centre buildings, operators, customers or servers sit behind the measurement. Treating that number as an installed-base census would add information the study did not collect.
The second denominator is protocol response. Of the measured endpoints, 24,650 returned at least one RAKP exchange containing material derived from a password before the client had proved its identity. This is the mechanism recorded in CVE-2013-4786: an outside party can obtain an HMAC and test password candidates offline. The reply creates a guessing opportunity; it is not itself the password.
The third denominator is recovery and use. A candidate may match the captured material without anyone opening a management session. Lava says it did not authenticate to the two modern Supermicro systems for which it recovered the documented factory-format password. Nothing in the study establishes that all 24,650 responses yielded a credential, that every recovered credential remained valid, or that an intruder controlled every responding machine.
These states form a ladder, not synonyms: reachable endpoint, pre-authentication response, matched candidate, recovered credential, authenticated session and compromise. The research climbs several rungs in limited cases and deliberately stops before login. A credible risk assessment should do the same.
The BMC creates a failure domain below the operating system
A baseboard management controller is designed to work when the host operating system cannot. Administrators use it to power-cycle equipment, inspect a console, attach virtual media and manage firmware. That independence is the product’s value: a failed server can still be reached through a separate control path.
The same separation makes the BMC a distinct failure domain. Endpoint protection, host firewalls and operating-system authentication do not necessarily govern a controller that has its own network interface and credentials. If the management interface is public, an operator can harden the application stack while leaving a lower, more privileged plane exposed.
This is why the issue cannot be reduced to password hygiene. A stronger password raises the cost of offline guessing, but public reachability still gives strangers access to an authentication exchange that should normally be available only to authorised administrators. The architecture has already surrendered one boundary before the quality of the credential is tested.
For data-centre operators and hosting providers, that boundary also sits across organisational hand-offs. Hardware vendors define defaults and features. Integrators cable the management network. Operators configure firewalls, VLANs and access lists. Customers may receive delegated console access. A weakness becomes material when these responsibilities leave a privileged interface outside the intended administrative enclave.
The protocol flaw is old; the deployment measurement is new
CVE-2013-4786 was first published in July 2013. It describes the IPMI 2.0 RAKP exchange and the ability to take a password-derived HMAC from message 2 for offline guessing. Lava has not discovered a new 2026 cryptographic flaw. It has measured how often the old mechanism was still presented by a public interface in one contemporary scan.
That timeline matters for accountability. A newly discovered flaw can leave operators waiting for a vendor patch or enough information to assess exposure. A thirteen-year-old protocol record changes the question. The relevant controls have long been known: restrict reachability, separate the management plane and avoid weak or predictable credentials.
Supermicro’s own BMC security guide says the controller should not be exposed to the internet or to unauthorised users outside a firewall. It describes the standard RAKP hash as weak and recommends blocking UDP 623 on unsecured networks, limiting access to known addresses, using a distinct management VLAN and protecting the subnet with a firewall.
The gap in 2026 is therefore not simply between secure and insecure silicon. It is between documented operating guidance and observed deployment. The measurement cannot say why each endpoint was public. Some may be temporary, misidentified or deliberately restricted elsewhere. But a pre-login RAKP response on a public address proves that the network perimeter allowed the exchange to begin.
Weak words and factory formats are different categories
Lava reports two separately measured matching groups. For 6,240 endpoints, an empty username produced material matching a weak-password candidate. For 2,340, a named account produced material matching a common-password wordlist. Those figures should not be added to a vague claim that a fixed share of “all hashes was cracked”. They use different account conditions and describe matches against specified candidate sets.
Predictable factory formats add another mechanism. Since November 2019, Supermicro says affected new systems have shipped with a unique preprogrammed BMC password instead of the shared ADMIN default. Unique is better than shared: compromising one printed credential does not automatically unlock an entire fleet. Yet uniqueness does not by itself guarantee high guessing cost if the format has limited possibilities and the RAKP exchange can be captured publicly.
Lava says it recovered the documented ten-uppercase-character factory-format password for two modern Supermicro X13DEM systems at an unnamed GPU provider. The researchers did not authenticate, disclosed the issue and report that the provider fixed it. That is evidence about two systems and one remediated exposure, not a verdict on every X13DEM installation or every Supermicro customer.
The HPE example is a laboratory cost demonstration, not an internet population result. Lava reports that a complete search of the documented eight-character iLO factory format took about 32 seconds per captured response on eight RTX 6000 PRO GPUs. It does not show that every HPE system used that format, was publicly exposed or had its credential recovered in the wild.
Vendor concentration cannot replace an operator denominator
Supermicro hardware represented more than half of responding BMCs in Lava’s dataset. That is a share of responses observed by this scan. It is not a share of Supermicro’s installed fleet, and it does not establish a vendor defect rate without knowing the number of deployed systems, their network placement and which models were reachable.
The distinction matters commercially. Supermicro and HPE can change shipped defaults, expand password spaces, update firmware and publish guidance. Operators decide whether the interface is routed publicly, which source addresses may reach it, whether credentials are rotated and whether logs enter a monitored security process. Integrators and hosting customers can influence the same controls.
Accountability is therefore layered. Protocol design determines what a compliant exchange reveals. Factory policy determines the starting credential. Deployment determines who can ask the controller to respond. Monitoring determines whether an unexpected request is noticed. A single vendor count cannot absorb all four.
The study is most useful as an exposure signal for the ecosystem, not a league table. Owners should search their own address space, inventories and firewall policy for management interfaces; they should not assume that a low or absent vendor count in an external scan proves safety.
Isolation is the primary control, not a cosmetic upgrade
The shortest remediation is to make the privileged plane private. Block public access to UDP 623, place BMCs on a dedicated management network and require administrators to arrive through a controlled VPN or bastion. Known-source access lists and firewalls should enforce the same boundary even when a device is misconfigured.
Credentials still matter inside that enclave. Factory passwords should be rotated, abandoned accounts removed and weak or legacy authentication disabled where supported. Firmware should be kept current. But credential work is a second layer rather than permission to retain public exposure.
Modern management interfaces can use Redfish over TLS, yet transport security does not turn the public internet into a trusted management network. Lava’s recommendation is to use such interfaces inside the isolated plane. Encryption protects a session; it does not decide who should be able to reach the login surface.
Separate monitoring closes the operating loop. BMC authentication events, configuration changes, firmware actions and network flows need visibility distinct from host telemetry. Otherwise an organisation may lose the very server that would have reported the management-plane action. Inventory should also reconcile physical assets, controller addresses and ownership so that an old maintenance route does not survive after a server or customer changes.
The next measurement should test persistence and control
The May scan is a point-in-time picture. The first follow-up question is whether the same exposure persists after disclosure. A repeated, methodologically comparable measurement could show whether the number of public endpoints and pre-authentication replies falls, but it would still need to avoid treating address churn as a fixed population.
The second question is control quality. How many operators restrict the management plane to private routing? How many allow only known source addresses? How many rotate factory credentials at commissioning and monitor failed authentication separately? Those measures connect internet exposure to practices an operator can change.
The third question is outcome, where this study is intentionally silent. Evidence of exploitation would require logs, authenticated sessions, unauthorised actions or incident records. None should be inferred from a RAKP reply alone. Responsible disclosure and the unnamed provider’s reported fix show that remediation can occur without the researchers crossing that line.
Lava’s most consequential result is therefore not a count of breaches. It is a count of times a privileged control plane answered a question from the public internet before knowing who was asking. In infrastructure security, the safest password exchange is often the one an unauthorised network can never reach.