---
schema: 1
kind: vulnerability
title: "CVE-2013-4786 — 24,650 internet-exposed BMCs hand a crackable password hash to any unauthenticated caller, and Lava found ransom notes on live management interfaces"
headline: "A 22-year-old IPMI design flaw hands the password hashes of exposed server management controllers to anyone, and offline cracking leaves no trace"
summary: >
  Lava scanned the internet for baseboard management controllers on 2026-05-06 and found 36,872 exposed
  IPMI hosts, of which 24,650 returned a password-derived HMAC-SHA1 authentication value before the client
  had authenticated at all — CVE-2013-4786, a design flaw in the IPMI 2.0 RAKP handshake present in the
  specification since 2004, for which no vendor patch is on offer: remediation is exposure removal and
  credential replacement. Because the hash comes
  back once per request rather than per login attempt, an attacker cracks it entirely offline with no
  lockout, no rate limit and no failed-login record on the controller, and the factory password formats
  used by Supermicro and HPE iLO are short enough to search exhaustively on GPU hardware. Lava found a live
  HPE iLO 4 login page displaying a ransom note, making this confirmed in-the-wild abuse of the server
  management plane rather than a theoretical exposure.
discovered_at: "2026-07-30T04:50:00Z"
event_date: "2026-07-29"
run_id: 2026-07-30T0409Z-intel
priority: high
immediate_action: null
tags: [vulnerabilities, info-disclosure, pre-auth, actively-exploited, no-patch, default-config, ransomware]
regions: [global]
sectors: [energy, telco, public-sector, finance, healthcare]
entities: []
techniques: [T1110.002, T1078.001, T1542.001]
affected_products: ["Supermicro BMC (IPMI)", "HPE iLO"]
cves:
  - id: CVE-2013-4786
    cvss: "7.5"
    epss: null
    type: info-disclosure
    vector: zero-click
    auth: pre-auth
    status: [exploited, no-patch]
    affected: "The RAKP authentication mechanism of the IPMI 2.0 specification itself, universal to any BMC implementing IPMI 2.0 RAKP (in the specification since its 2004 release). Confirmed at scale in Lava's tested population on Supermicro BMC and HPE iLO implementations; Supermicro hardware accounted for more than half of the responding controllers in that dataset."
    fixed: "No vendor patch is offered for the RAKP design weakness itself; Lava frames remediation as network- and credential-level, and its own prior-work section links an HPE advisory covering the same password-hash disclosure on earlier iLO generations. Remediation in practice: remove IPMI/BMC reachability from the public internet, replace factory-issued passwords, and disable legacy IPMI 1.5, cipher-suite-0 and anonymous/NONE authentication."
sources:
  - url: "https://lavahq.io/research/bmc-exposure-alert"
    publisher: "Lava"
    date: "2026-07-29"
    role: primary
  - url: "https://www.darkreading.com/cyber-risk/flaw-exposes-data-centers-server-takeover"
    publisher: "Dark Reading"
    date: "2026-07-28"
    role: corroborating
closed_sources: []
evidence:
  - quote: "On May 6, 2026, the query returned 36,872 unique hosts exposing IPMI to the public internet."
    publisher: "Lava"
  - quote: "Approximately two-thirds of the exposed BMCs we tested returned at least one password-derived authentication hash before client authentication was complete."
    publisher: "Lava"
  - quote: "During our research, we found an exposed HPE iLO 4 login page displaying a ransom note in its Security Notice panel. The message claimed that the server's data had been encrypted and demanded 0.3 BTC."
    publisher: "Lava"
  - quote: "During the research, we identified compromised systems belonging to one of the world's largest automotive component manufacturers. Multiple exposed servers displayed ransomware notes and payment demands, indicating that the company was being targeted as part of an active attack campaign."
    publisher: "Dark Reading"
  - quote: "The main fix is simple: IPMI should not be reachable from the public internet."
    publisher: "Lava"
verification: multi-source
sourcing_note: >
  The exposure statistics, the cracking measurements and both in-the-wild exploitation observations
  originate solely with Lava; Dark Reading's account of the automotive-component manufacturer comes from its
  own interview with Lava's CTO rather than from separate telemetry, so it corroborates the reporting but
  not the underlying measurement. Lava states it performed all cracking offline against captured hash
  material and did not attempt to authenticate to any controller. The underlying protocol flaw and its
  pre-authentication hash-disclosure mechanism were independently confirmed this run against the CVE's own
  vulnerability-database record, which is not cited as a source because per-CVE database pages are derived
  data sheets under this pipeline's sourcing policy.
confidence: high
update_of: null
references: []
deep_dive: true
deep_dive_category: other
org_triage: null
classification:
  reliability: B
  credibility: 2
watchlist_hit: false
actions:
  - "Block inbound UDP/623 at the network edge and confirm no BMC or IPMI interface answers from the internet. Any controller that has accepted an inbound UDP/623 session from outside the management network should be treated as already compromised rather than merely exposed, because the hash disclosure leaves no record on the controller itself."
  - "Replace factory-issued BMC passwords on every Supermicro and HPE iLO host that has been internet-reachable, and treat the old password as recovered regardless of when the exposure ended: both factory formats are fixed-length and fully searchable offline, so a hash captured during the exposure window stays crackable afterwards."
migrated_from: null
---

**Background.** The flaw at the centre of this research is not new. CVE-2013-4786 was assigned in 2013 and the weakness it describes has been in the IPMI 2.0 specification since that standard shipped in 2004 ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)). The management layer it exposes has drawn attacker attention before: Lava cites prior public research on iLOBleed, a persistent iLO 4 rootkit associated with destructive attacks, as precedent for adversary interest in this layer ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)). What is new is the measured scale of exposure thirteen years after disclosure, and evidence that it is being used.

A baseboard management controller is the dedicated, OS-independent processor on a server motherboard that provides out-of-band control — power, reboot, virtual media, firmware, health telemetry — over IPMI or the newer Redfish API. Control of a BMC is therefore control of the machine beneath any operating system on it. Lava queried Shodan for hosts answering on UDP/623 and found "36,872 unique hosts exposing IPMI to the public internet" on 2026-05-06, observing roughly sixty previously-unseen addresses newly exposing IPMI each day between May and July ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)).

The exploitation primitive is a single unauthenticated request. The client sends a RAKP Message 1 naming the account it wants; the controller replies in RAKP Message 2 with an HMAC-SHA1 computed over that account's password, before the client has authenticated ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)). Lava found that "approximately two-thirds of the exposed BMCs we tested returned at least one password-derived authentication hash before client authentication was complete" — 24,650 of the 36,872 hosts ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)). Two further slices of that population needed no cracking effort at all: 6,240 hosts accepted an empty username paired with a password that matched a common wordlist, and 2,340 had a named account such as ADMIN or root whose password matched a wordlist ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)).

What makes this materially worse than an ordinary weak-credential finding is that the hash is returned per request rather than per authentication attempt, so guessing happens entirely offline. No lockout triggers, no rate limit applies, and no failed-login entry is written on the controller. That property also disposes of the obvious detection idea: BMC authentication logs cannot surface this technique, because the attacker never attempts a login there.

Vendor factory-password schemes are the second half of the problem, because their formats are constrained enough to exhaust. Supermicro replaced its old shared ADMIN:ADMIN credential in November 2019 with a unique password printed on the chassis sticker, but the format is exactly ten uppercase letters; Lava puts that keyspace at "26^10, or approximately 141 trillion possible passwords" and assesses that "on a modern server with eight GPUs running Hashcat, the complete candidate space could be searched in approximately one hour" ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)). HPE iLO's factory format is eight characters of uppercase letters and digits, a keyspace roughly fifty times smaller, and on Lava's own eight-GPU lab server "the same search took approximately 32 seconds per response" ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)). A unique-per-chassis factory password is not a defence when its format is public and its length is fixed.

This is being abused now, not hypothetically. Lava reports that "during our research, we found an exposed HPE iLO 4 login page displaying a ransom note in its Security Notice panel," claiming the server's data had been encrypted and demanding 0.3 BTC ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)) — Lava could establish that the management interface had been accessed and altered by an unauthorised party, not that the underlying data was in fact encrypted. Separately, Lava's CTO told Dark Reading that "during the research, we identified compromised systems belonging to one of the world's largest automotive component manufacturers," with multiple exposed servers displaying ransom notes and payment demands ([Dark Reading, 2026-07-28](https://www.darkreading.com/cyber-risk/flaw-exposes-data-centers-server-takeover)).

Migrating to Redfish does not by itself resolve this. The RAKP weakness is specific to the legacy IPMI 2.0 handshake, but Lava notes that in many implementations the interfaces share one user database, so a password recovered through IPMI often authenticates directly against the web UI or the Redfish API; its guidance is to "prefer Redfish over TLS within an isolated management network. Neither Redfish nor IPMI should be exposed directly to the public internet" ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)). Supermicro, responding to Lava's June 2026 disclosure, accepted that the cracking scenario is plausible with modern multi-GPU hardware, restated its guidance to rotate default passwords at setup and keep management networks off the public internet, and said it would review longer passwords and a wider character set for future hardware ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)).

Detection has to move to the network, because the controller is structurally blind here. The only viable telemetry is network-flow and firewall logging of inbound UDP/623 from outside the management network; the platform-firmware layer is also where recovery gets expensive, since Lava flags that persistence at this level can survive operating-system reinstallation and disk replacement. Hardening is exposure removal first — Lava's own summary is that "the main fix is simple: IPMI should not be reachable from the public internet" ([Lava, 2026-07-29](https://lavahq.io/research/bmc-exposure-alert)) — followed by replacing factory credentials during provisioning, disabling IPMI 1.5, cipher-suite-0 and anonymous or NONE authentication, and confining controller access to a dedicated management network reached through a bastion.

**Defender takeaway:** treat any BMC that has been internet-reachable as having already surrendered its password, and plan for platform-level recovery rather than an OS rebuild if one shows signs of tampering. For Swiss and European operators the exposure concentrates wherever bare-metal is self-run or colocated — data centres, energy and telco plant, and the on-premises estates still common across public-sector infrastructure.

**Triage:** legitimate BMC traffic originates inside a known management VLAN from a small set of administrative hosts. An inbound UDP/623 session from a WAN-facing or unrecognised source is not merely suspicious but inherently anomalous, since there is no benign reason for an out-of-band management controller to answer the public internet; and because the disclosure step generates no authentication event, the absence of suspicious BMC login entries is not evidence that nothing happened.
