Security researchers found 36,872 server management interfaces exposing IPMI to the public internet. Of those, Lava reports that 24,650 returned at least one password-derived RAKP response before the requesting client had authenticated.
Almost 67 percent of the tested interfaces exposed material that an unauthenticated party could use for offline password guessing. The finding alone does not show that any of those servers were compromised. Lava recovered common passwords for 2,340 named accounts and weak passwords tied to empty usernames on 6,240 systems. The researchers say they did not use recovered passwords to log in.
IPMI sends the cracking target before it trusts the client
The weakness is CVE-2013-4786, a property of the IPMI 2.0 RMCP+ Authenticated Key-Exchange Protocol. During RAKP authentication, a baseboard management controller can return an HMAC-SHA1 value calculated from the account password and session values known to the requester.
An unauthenticated party able to reach UDP port 623 can collect that response and test password candidates locally. The BMC receives one request for the captured exchange, while the guessing occurs elsewhere. Ordinary failed-login thresholds therefore do not describe the full exposure.
Figure details
An unauthenticated requester starts an IPMI 2.0 RAKP exchange with a BMC over UDP port 623. The BMC returns session values and a password-derived HMAC before client authentication completes. The requester can then test password candidates offline, so repeated guesses do not create repeated BMC login failures. If a password is recovered and later used, the path returns to the BMC as privileged management access. The figure separates confirmed protocol behavior from the possible later use of a recovered credential.
Lava measured the exposure on May 6, 2026, and repeated measurements through July. Its report says 60 previously unseen IP addresses appeared in the exposed population on an average day. More than half of the responding systems appeared to be Supermicro hardware.
The researchers also tested predictable factory-password formats. They recovered the ten-uppercase-letter passwords of two 2023 Supermicro systems operated by a GPU provider whose policy permitted the test. In a lab, they searched the complete eight-character HPE iLO factory-password space in about 32 seconds per captured response on eight RTX 6000 PRO GPUs. Cracking time varies with the password format, hardware, and search method.
BMC access sits below most host defenses
A BMC can power-cycle a server, expose its console, mount virtual media, update firmware, and change low-level platform settings while the host operating system is unavailable. Host endpoint telemetry may not record activity performed through that separate management processor.
Lava found an exposed HPE iLO 4 login page displaying a ransom demand. The researchers could not confirm that the underlying server was encrypted. The altered page proves access to that management interface, while the claimed effect remains unverified.
The investigation must therefore cover the out-of-band management plane and the host it controls. Removing public exposure prevents another RAKP capture, but it cannot show whether previously exposed credentials were recovered or used.
Close the incident with management-plane evidence
First, inventory every BMC and test from outside the approved administrative network that UDP port 623 and vendor web or API surfaces are unreachable. Disable IPMI-over-LAN where operations do not require it. Dell states that CVE-2013-4786 has no patch and recommends disabling IPMI-over-LAN. Where IPMI must remain, restrict it with an isolated management network and access-control lists.
Second, replace every factory, reused, weak, or potentially exposed BMC credential. Do not treat password rotation as sufficient evidence. Review BMC audit and lifecycle records for successful sessions, account changes, virtual-media mounts, console access, power events, firmware updates, network-setting changes, and cleared logs. Compare firmware and configuration with a trusted baseline, and check bastion, VPN, firewall, DHCP, switch, and network-flow records for unapproved paths to the management network.
Finally, inspect the managed host for changes that could have arrived through console or virtual media, then validate the recovery path. The incident can close when no public management route remains, credentials are unique and replaced, only approved administrative systems can reach the BMC, controller firmware and configuration match a trusted state, management and adjacent network records show no unexplained access, and the host passes a known-good integrity check.
Missing BMC logs, unverified firmware, absent flow history, or evidence that audit records were cleared leaves a material blind spot. In that case, rebuild trust at the platform layer with vendor guidance, verified firmware recovery, or hardware replacement where integrity cannot be established.