Security researchers have warned that thousands of Internet-exposed server management controllers remain vulnerable to a decades-old flaw that can allow attackers to recover credentials and gain privileged access to data center hardware.
Researchers at Lava found 36,872 Internet-exposed IPMI services, with 24,650 returning password-derived authentication material before login because of CVE-2013-4786, a long-known weakness in the IPMI 2.0 authentication protocol. More than 30% of the returned hashes were associated with passwords that could be recovered using common wordlists or predictable factory-password formats.
The issue affects Baseboard Management Controllers, or BMCs — small management processors built into servers that allow administrators to control hardware remotely, even when the operating system is powered off or unresponsive.
Why BMCs Are So Powerful
A BMC is not just another management interface.
It sits below the operating system and can control core server functions such as power cycling, remote console access, virtual media mounting, firmware updates, hardware telemetry, and low-level platform configuration. Lava describes BMCs as one of the most privileged control points in a data center.
That makes BMC compromise especially dangerous.
If attackers gain access to a BMC, they may be able to control the server from beneath the operating system. Traditional endpoint security tools may not see this activity because they mostly monitor the OS, kernel, containers, and workloads — not the out-of-band management processor running alongside them.
The 20-Year-Old Weakness
The core issue is CVE-2013-4786, a vulnerability in the IPMI 2.0 authentication flow.
An unauthenticated attacker who can reach UDP port 623 can request an authentication response from the BMC. That response may contain password-derived material, allowing the attacker to take the hash offline and try password guesses without repeatedly interacting with the target system.
This is important because offline cracking is much harder to detect than normal login guessing.
Instead of generating thousands of failed login attempts against the BMC, the attacker can capture the authentication material once and test password candidates elsewhere.
Weak, reused, factory-set, or predictable passwords become the real problem.
What Researchers Found
Lava’s scan found a large number of exposed and weakly configured systems.
Among the tested Internet-facing BMC endpoints:
- 36,872 exposed IPMI hosts were identified
- 24,650 returned at least one RAKP response before client authentication
- 6,240 accepted empty usernames with weak password candidates
- 2,340 had named accounts such as
ADMINorrootmatching common password wordlists
In many cases, matching passwords were found quickly during offline analysis. Lava says it did not use the recovered passwords to authenticate to affected BMCs.
Unique Factory Passwords Are Not Always Enough
A major lesson from the research is that “unique factory password” does not automatically mean “safe.”
Some Supermicro systems use a ten-character uppercase factory password format. That sounds stronger than shared default credentials, but Lava found that the constrained format can still be practical to crack in targeted scenarios using modern GPU hardware.
The researchers also tested an HPE iLO factory-password format in their lab and found that, with GPU hardware, the candidate space could be searched very quickly per captured response.
The problem is not only weak passwords.
It is the combination of predictable password formats, exposed IPMI, and a protocol flaw that allows offline cracking.
Why This Matters for AI and GPU Infrastructure
The risk is especially serious for modern AI and GPU infrastructure.
AI data centers often contain large numbers of high-value GPU servers connected through shared management networks, provisioning systems, storage, and orchestration tooling. Lava warns that a single compromised BMC in these environments can become a path toward additional hosts, shared infrastructure, and potentially broader management-plane compromise.
This is particularly important for bare-metal GPU providers and “neocloud” environments, where customer workloads may run on dedicated servers but the provider’s management plane still spans many systems.
If BMC networks are poorly segmented or lightly monitored, one exposed controller can become a privileged foothold.
Evidence of Real-World Targeting
This is not only a theoretical exposure.
Lava reported finding evidence that exposed BMC interfaces were already being targeted. In one case, researchers found an Internet-exposed HPE iLO login page displaying a ransom note in the Security Notice panel, suggesting unauthorized access to the management interface.
Dark Reading also reported that Lava found compromised systems linked to a major automotive component manufacturer, with exposed servers displaying ransomware notes and payment demands.
That means defenders should treat exposed BMCs as urgent, not as forgotten administrative leftovers.
What Attackers Could Do
A compromised BMC can give attackers a dangerous level of control.
Possible impacts include:
- remote console access
- server power control
- virtual media abuse
- firmware manipulation
- low-level configuration changes
- persistence below the operating system
- lateral movement through management networks
- access to provisioning and internal management systems
- ransomware staging or recovery disruption
In worst-case scenarios, recovery may require firmware reflashing, platform-level validation, vendor-assisted remediation, or even hardware replacement if trust in the management layer cannot be restored.
Why Traditional Monitoring May Miss It
Most security monitoring focuses on the operating system and application layer.
BMCs sit outside that boundary.
They may have their own network interfaces, credentials, firmware, logs, and management protocols. If those systems are not monitored separately, attackers can operate in a blind spot.
This is why BMCs should be treated as part of the critical security perimeter, not as simple hardware utilities.
A data center is only as secure as its management plane.
What Organizations Should Do
The first and most important step is simple: IPMI should not be reachable from the public Internet.
Lava recommends blocking UDP port 623 at the network edge, replacing factory-issued passwords during provisioning, disabling legacy or weak options such as IPMI 1.5, cipher suite 0, anonymous accounts, and NONE authentication, and restricting BMC access to private management networks, VPNs, bastion hosts, or other controlled administrative paths.
Organizations should also:
- isolate BMCs on dedicated management networks
- apply strict ACLs to management interfaces
- rotate default and reused BMC credentials
- monitor BMC logs and management-network activity
- inventory all exposed IPMI, Redfish, iLO, iDRAC, XClarity, and Supermicro BMC interfaces
- review firmware versions and vendor guidance
- disable unused remote console and virtual media features
- treat BMC compromise as a platform-level incident
Where supported, Redfish over TLS should be used only inside isolated management networks — not exposed directly to the public Internet.
Final Thoughts
The exposure of thousands of BMCs shows that old infrastructure weaknesses can remain dangerous for decades.
CVE-2013-4786 is not new, but modern GPU cracking, predictable factory-password formats, and publicly exposed management interfaces make it newly relevant at data center scale.
Server management controllers are not secondary systems. They are privileged control planes.
If attackers compromise them, they can operate below the operating system, bypass many traditional controls, and potentially move through the data center management network.
Organizations should remove BMCs from the public Internet, rotate factory credentials, isolate management networks, and continuously monitor this layer as critical infrastructure.
