24,650 exposed BMCs leak IPMI password hashes — and there is no patch

On 28 July 2026, researchers at Lava published the results of an internet-wide scan of IPMI services. Of 36,872 exposed baseboard management controllers, 24,650 — just under two thirds — returned a password-derived authentication hash to an unauthenticated client that simply asked for one. More than 14,000 of them sit in the United States, with the remainder concentrated in Germany, China, the Netherlands and the UK, according to BleepingComputer's coverage.

The interesting part is not the number. It is that there is no patch, there has never been a patch, and there will not be one. The defect is in the IPMI 2.0 specification, published in 2004. Every conformant implementation reproduces it. This article is about what you actually do when the vulnerability management process — find it, patch it, close the ticket — has no valid move.

What the exposed BMCs actually leak

A baseboard management controller is a small independent computer soldered onto the motherboard of nearly every rack server. It has its own processor, its own memory, its own network stack and its own power domain. It runs when the host is powered off. It can mount virtual media, drive the console, power-cycle the chassis and reflash firmware. Dell calls it iDRAC, HPE calls it iLO, Lenovo calls it XCC, and a large slice of the market is Supermicro — which accounted for more than 50% of the responding controllers in Lava's dataset.

CVE-2013-4786 (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, CWE-255) describes the mechanism precisely: the RMCP+ Authenticated Key-Exchange Protocol used by IPMI 2.0 returns, in RAKP message 2, an HMAC-SHA1 computed over the account password and session values the requester already knows. The controller sends this before authentication completes. That is by design — it is how the mutual-authentication handshake is supposed to work.

The consequence is that anyone who can reach UDP 623 gets an offline cracking target. This matters more than it sounds:

• No lockout applies. Account lockout, rate limiting and failed-login alerting all operate on login attempts. There are none here. One request yields one hash; every subsequent guess happens on the attacker's own hardware.
• No log entry is generated on most implementations, because no authentication was attempted.
• The guess budget is unbounded. This is the difference between a password policy that has to survive a few thousand online attempts and one that has to survive a few trillion offline ones.

Lava found that more than 30% of the recovered hashes corresponded to passwords crackable from common wordlists and predictable factory formats. Separately, 6,240 hosts (16.9%) accepted an empty username, and 2,340 (6.3%) used administrator passwords matching public dictionaries.

Why the IPMI password hash problem cannot be patched away

The factory-default password schemes are what turn a theoretical offline attack into an hour of GPU time. Vendors print a per-chassis password on a sticker, drawn from a fixed and narrow format — which means the keyspace is known to the attacker in advance.

Vendor	Factory password format	Keyspace	Offline recovery (Lava)
Supermicro	10 uppercase letters	26¹⁰ ≈ 141 trillion	~1 hour, 8-GPU server
HPE iLO	8 chars, uppercase + digits	36⁸ ≈ 2.8 trillion	~32 seconds, 8× RTX 6000 PRO
HPE iLO	same	same	~1 day, single Apple M3

A single day of one laptop's time recovers an iLO factory password. Thirty-two seconds if you rented the right box. Supermicro told the researchers the scenario was plausible and said it would review default password policy for future revisions — which helps the servers nobody has bought yet.

Dell's position on the underlying flaw has been consistent for over a decade and is worth stating plainly, because it reframes the whole exercise:

This is an inherent problem with the specification for IPMI v2.0.

There is no fixed version. There is no advisory to track. The Metasploit modules that dump these hashes (auxiliary/scanner/ipmi/ipmi_dumphashes) and abuse cipher zero have shipped since Dan Farmer and HD Moore's original IPMI research in 2013, and Tenable has had a Nessus plugin for it since then. Everything about this attack has been public, tooled and trivially automatable for thirteen years. The exposure persisted anyway — and Lava observed roughly 60 newly exposed IPMI addresses appearing every day between May and July 2026.

The rest of the IPMI family

Treating this as a single CVE understates it. The same specification has produced a steady supply of authentication defects across vendors and across two decades:

• CVE-2013-4782 — Supermicro BMC cipher suite 0. An attacker supplies any password and executes arbitrary IPMI commands. CVSS v2 10.0. Cipher zero is a specification-mandated "no authentication" mode that shipped enabled.
• CVE-2013-4037 and CVE-2013-4038 — the same RAKP class in IBM's Integrated Management Module. Different vendor, same protocol, same year.
• CVE-2021-39296 — OpenBMC 2.9: crafted IPMI messages bypass authentication entirely and yield full system control. The open-source reimplementation inherited the class.
• CVE-2024-3411 — CVSS 9.1, published April 2024, CWE-331: IPMI authenticated sessions do not generate enough entropy, so predictable session IDs allow session hijacking. Confirmed against Dell iDRAC8 and Intel's own IPMI 2.0 implementation.

Twenty years after publication, the specification was still producing critical authentication flaws in 2024. That is the actual finding. Anyone planning to manage this risk one CVE at a time is signing up for a permanent subscription.

The most privileged computer nobody monitors

A compromised BMC is not a compromised server. It is worse, in a specific way that changes incident response.

The controller sits below the operating system. It cannot run your EDR agent — there is nowhere to install one. It does not appear in your OS patch inventory. It frequently does not appear in the CMDB at all, because it was provisioned by whoever racked the hardware. And from it, an attacker can mount an ISO as virtual media and boot the host from it, read and write the host's memory and disks, capture the console, or reflash firmware to persist across a full OS reinstall.

That last one is not hypothetical. The iLOBleed rootkit, documented persisting inside HPE iLO 4 firmware, survived disk wipes and was linked to destructive attacks on servers. Lava's scan turned up an exposed iLO 4 login page already displaying a ransom note demanding 0.3 BTC and claiming RSA-2048 encryption — someone got there first.

Both regulators moved on this. NSA and CISA published joint guidance on hardening BMCs in June 2023, warning that a neglected BMC gives an adversary "a beachhead with pre-boot execution potential". And on the same day the Lava research landed, CISA, the FBI and the Australian Cyber Security Centre released CI Fortify — Advice for isolating vital systems, which states that the network management zones used to administer infrastructure must themselves be isolated from attackers. That is the control. It is the only control.

Remediation

There is no patch, so this runbook is longer than usual on discovery, controls and hunting — and has nothing at all under "install the fixed version".

1. Am I affected?

Assume yes if you own physical servers. The question is whether the controller is reachable and whether the password is factory-issued.

# Find IPMI listeners on your ranges (UDP 623 — TCP scans will miss all of them)
nmap -sU -p 623 --script ipmi-version 10.0.0.0/8

# Confirm the RAKP hash actually comes back, per host
msfconsole -q -x "use auxiliary/scanner/ipmi/ipmi_dumphashes; \
  set RHOSTS 10.0.0.0/24; set OUTPUT_HASHCAT_FILE /tmp/ipmi.hashes; run; exit"

# Test for cipher zero — full auth bypass, worse than the hash leak
msfconsole -q -x "use auxiliary/scanner/ipmi/ipmi_cipher_zero; set RHOSTS 10.0.0.0/24; run; exit"

# From the host itself, enumerate accounts and channel config
ipmitool user list 1
ipmitool lan print 1

Then check your external attack surface honestly: query your own public ranges for UDP 623 from outside the network. Roughly 60 organisations a day discover they belong in this dataset by accident.

2. Patch — what is actually available

For CVE-2013-4786 itself: nothing, permanently. What is patchable:

• BMC firmware — update to current for iDRAC / iLO / XCC / Supermicro. This closes implementation bugs such as CVE-2021-39296 and CVE-2024-3411, not the RAKP disclosure.
• Migrate to Redfish where the hardware supports it, and disable the IPMI-over-LAN interface entirely. Redfish is HTTPS-based and does not have the pre-auth hash exchange. This is the only change that genuinely removes the vulnerability rather than hiding it.

3. Can't remove IPMI? Compensating controls

These are not "nice to have" here — they are the remediation:

• Block UDP 623 at every network edge, and confirm with an outside-in scan rather than a firewall-rule review.
• Move every BMC to a dedicated out-of-band management VLAN, reachable only via a bastion or VPN. This is the specific control both the NSA/CISA CSI and CI Fortify call for.
• Rotate every factory password. Long and random — the keyspace, not the entropy of your policy, is what determines survival. If the password is on the chassis sticker, treat it as public.
• Disable cipher suite 0, IPMI 1.5, the anonymous/null user, and "NONE" authentication. Cipher zero makes the hash leak irrelevant because no cracking is required at all.
• Set BMC account passwords to values not used anywhere else. The hash you leak becomes a credential-stuffing seed for the rest of the estate.

4. Hunt for compromise

Signal	Where	ATT&CK
Inbound UDP 623 from outside the management VLAN	Firewall / netflow	T1046 Network Service Discovery
RAKP message 2 responses to external sources	Wire capture on the mgmt segment	T1190 Exploit Public-Facing Application
Successful BMC login from a new source ASN or geo	BMC syslog (forward it — most don't)	T1078.001 Valid Accounts: Default Accounts
Virtual media mount / ISO attach events	iDRAC LC log, iLO IML, XCC event log	T1542.001 Pre-OS Boot: System Firmware
Unexpected chassis power cycles or console (KVM) sessions	BMC event log	T1021 Remote Services
Firmware version mismatch vs your golden image	Vendor inventory API / Redfish	T1542.001
Offline cracking follow-through: BMC creds reused on OS accounts	Identity logs	T1110.002 Brute Force: Password Cracking

Pull the BMC's own event log for the full retention window, not just the last week — this exposure has been reachable for as long as the host has been racked.

5. Eradicate and verify

Order matters. Rotating credentials before isolating the interface just leaks the new hash.

1. Isolate first — pull the BMC off the routable network or block 623 at the edge.
2. Reflash BMC firmware from vendor-signed images, and do not trust an in-band update path on a host you suspect. Firmware implants such as iLOBleed survive OS reinstalls and can falsify the version string the controller reports.
3. Rotate BMC credentials, then every credential that BMC could reach — console sessions capture what was typed at them.
4. Re-verify from outside: rescan your public ranges for UDP 623, and re-run ipmi_dumphashes from an untrusted network position. A clean result from inside the management VLAN proves nothing.
5. Record the residual risk formally. Because there is no patch, the risk is accepted permanently and the compensating control is the only thing standing between you and the finding. That acceptance needs to be documented, owned and re-tested — not assumed.

When there is no patch, the control is the evidence

This is where the usual compliance workflow breaks. An auditor's question — "show me that CVE-2013-4786 is remediated" — has no answer, because it never will be remediated. The honest answer is: the interface is not reachable, here is the proof, and here is the proof from last month and the month before. Segmentation is not a state you achieve once. It is a claim that decays every time someone racks a server, changes a firewall rule or stands up a new colocation cage.

Zero Hunt maps every finding, scan and remediation against 32 frameworks — including NIS2, ISO 27001, DORA and NIST CSF — with severity-weighted scoring and cross-framework control mapping, so an unpatchable protocol flaw is filed once as an accepted risk with a named compensating control, and satisfies the network-segregation and out-of-band-management requirements of all of them at once rather than three times over. Each report is ECDSA-signed at write time with chain-of-custody by construction, and the Trust Center exports the bundle an auditor asks for. The point is not the paperwork. It is that "we isolated the management plane" becomes a dated, signed, verifiable assertion instead of a claim someone makes from memory in a meeting.

Producing that evidence requires actually testing the boundary, which is the second half. The 10-agent AI swarm runs Recon against your real perimeter rather than your CMDB, and the Credential agent carries a corpus of 330+ default credential sets from SecLists — the same factory formats that made 2,340 of Lava's hosts trivially guessable. Every exploit runs in an ephemeral Docker container with optional gVisor hardening, so validating a management interface never puts the appliance host at risk. And because campaigns are change-triggered as well as scheduled, a new asset appearing on the perimeter — a freshly racked server whose BMC still has the sticker password — starts a full campaign within the hour, rather than waiting for the annual pentest to find what an internet-wide scanner finds in an afternoon.

The 24,650 organisations in this dataset did not decide to expose their server management plane. They just never checked, and nobody sent them a patch to remind them.

If you want to see what your perimeter actually answers on UDP 623, get in touch or read how exposure validation differs from exposure estimation.