We Counted 31,325 Exposed BMCs. Here Is What One Is Actually Worth: Your Host's RAM, Your Disk-Encryption Keys, and an Implant That Survives the Rebuild.

Earlier today we published a census: 31,325 baseboard management controllers answering the open internet, 28.8 percent of them concentrated in eight hosting networks, and roughly 24,650 handing out an authentication hash to anybody who asks before login.

A census tells you the size of a surface. It does not tell you what the surface is worth. This post is the second half, and the honest reason to write it is that we understated the first half. "An attacker can power-cycle your server and mount virtual media" is true and it is not the interesting part.

Here is the interesting part. Every link in the chain below is published, documented, and sitting on a shelf. None of it is our research. What is ours is the exposure count on the front of it — and the observation that nobody appears to have assembled these pieces in public and asked what the combination is worth.

Link one: exposure to credentials

IPMI 2.0's RAKP handshake returns a salted HMAC of the account password to an unauthenticated requester. This is not a vendor bug. It is how the protocol was specified in 2004, it has been publicly known for over a decade, and there is no patch, because removing it would mean not speaking IPMI.

The consequences are unusual. The hash is crackable offline, at leisure, on rented GPUs. Collecting it produces no failed-login event, because no login was attempted. Rotating the password does not help — the new password yields a new hash, handed out just as freely, to anyone who asks again.

So step one costs an attacker a UDP packet and provides the defender with no telemetry whatsoever.

Link two: credentials to code execution on the controller

This is where vendor firmware history stops being a footnote.

Supermicro published a BMC firmware advisory in July 2026 — this month — covering vulnerabilities discovered independently by researcher Anton Beidin and the team at Eclypsium, with every affected motherboard SKU requiring a BMC update. Supermicro is also the most-exposed BMC vendor in our census, at 1,922 internet-facing management consoles.

HPE's iLO has a longer record: CVE-2017-12542 was an authentication bypass with remote code execution in iLO4, and CVE-2021-29202 allowed arbitrary code execution against iLO from the host side.

The pattern that matters here is not any individual CVE. It is that BMC firmware is patched on a cadence measured in years, by people who did not know they owned a BMC, on machines whose uptime is the entire point.

Link three: the controller to your host's memory

This is the link that changes the severity class, and it is the one we left out this morning.

[CVE-2019-6260](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2019-6260) — known as Pantsdown, publicly documented by Stewart Smith — describes the ASPEED AST2400 and AST2500, the system-on-chip that runs the BMC in a very large share of the world's servers. The finding: AHB bridges exposed on the LPC and PCIe buses, and an X-DMA engine able to address the controller's entire memory bus. The compromise runs in both directions between host and controller.

Then somebody built the working version. BMCLeech, published through DFRWS in Forensic Science International: Digital Investigation, implements exactly this on OpenBMC: a custom kernel driver on the management controller performing DMA reads against host memory. The paper's framing is memory forensics — a legitimate, useful purpose. Its central technical finding is the part a defender needs to sit with:

The host operating system cannot detect that its memory is being read.

Not "it is difficult to detect." There is no event. Direct memory access is a hardware path that does not transit the operating system, so there is nothing for the OS to observe, log, or alert on.

Link four: an implant that survives your entire response

iLOBleed, analysed by Eclypsium, is a rootkit resident in iLO 4 firmware, tied to destructive attacks against servers. It is not a proof of concept.

Firmware lives on an SPI flash chip on the motherboard. A disk format does not touch it. An OS reinstall does not touch it. Replacing the disk does not touch it. It executes before any operating-system security control is loaded, at a privilege level above the kernel.

What the assembled chain defeats

Read the four links together and the defensive picture inverts.

Full-disk encryption becomes irrelevant. FDE protects data at rest. The volume key lives in host RAM while the machine is running, and link three reads host RAM. The encryption is not broken; it is simply not in the path.

EDR becomes blind, not degraded. Endpoint detection runs inside the operating system. A DMA read never enters the operating system. This is not an evasion technique to be signatured — there is no artifact.

Incident response becomes reinfection. The standard remediation for a compromised server — rebuild it — hands the machine back to an implant in firmware that the rebuild never touched.

And the thing that makes this land on ordinary companies rather than only on interesting targets: the machines most likely to have an exposed BMC are the cheap ones. Staging environments, QA clusters, regional nodes, the developer sandbox from three years ago. "It's only a staging box" has been a valid dismissal for a long time. It stops being valid the moment the box's RAM is readable, because staging environments are where production credentials go to live comfortably.

Why we are publishing this as a warning and not an incident

We have no evidence that any of this has been used against the population we counted. We want to be extremely clear about that, because the alternative framing would be more dramatic and less true.

What exists is a fully enumerated surface next to a fully published capability. The exposure count is ours, measured this afternoon. The DMA primitive is Pantsdown, 2019. The working implementation is BMCLeech, 2020. The in-the-wild firmware implant is iLOBleed. The fresh vendor advisory is three weeks old. Four different groups of people, none of them coordinating, each publishing one link of a chain for entirely legitimate reasons.

That is the definition of the signal we spend our time looking for: everything required for the event, assembled and public, before the event. Left of boom is not a prediction that something will happen. It is the observation that nothing further needs to be invented.

The three controls that actually survive this

Most advice about BMCs is a list. Here are the only three that hold up against the chain above.

One: the management plane is not on the internet, ever. This is the whole ballgame, because it breaks link one, and every subsequent link depends on it. A dedicated management VLAN with no internet route, or a VPN, or a bastion. Access to that network governed like physical access to the building — because a BMC gives an attacker what physical access gives them, from anywhere. If you rent bare metal, this is a question you ask your provider in writing, and a vague answer is a no.

Two: BMC firmware gets a patch cadence, in writing, like everything else. The Supermicro advisory is from this month. Somebody has to own noticing that, on hardware nobody thinks of as having software. Put BMC and BIOS advisories on the same review cycle as your OS patching, with a named owner. If you cannot say when your BMC firmware was last updated, that is the answer.

Three: BMC credentials are tier-zero. Not "infrastructure passwords." The same tier as your domain admin and your root CA, because functionally they sit lower than both. Separate credentials per machine, in the vault, rotated, never reused from the server build sheet. And accept that link one means the hash is gettable regardless — so the password must be long enough that offline cracking is not economical, which in practice means machine-generated and never typed by a human.

Two things worth adding for anyone doing IR on embedded or out-of-band systems: capture volatile artifacts before you touch anything, and remember that a clean disk is not a clean machine. If you have a genuine BMC compromise, the remediation is firmware reflash from known-good media, or the hardware does not come back into service.

The honest limits

We hold this at 95 percent, and this piece needs its boundaries drawn carefully because it is a chain argument.

We have not demonstrated the chain end to end. We measured the exposure. Every other link is other people's published research — Stewart Smith on Pantsdown, the DFRWS authors on BMCLeech, Eclypsium on iLOBleed and on this month's Supermicro advisory alongside Anton Beidin. Go read their work; it is better than our summary and the credit is theirs.

Not every BMC has unrestricted DMA to host memory. It varies by platform, by chip generation, by board design and by configuration. Pantsdown is specific to particular ASPEED parts. A defender should treat this as a capability class that may be present, not as a guaranteed property of every controller in the census.

The links have not been observed chained in the wild, to our knowledge. Each has been demonstrated individually. We are describing an assembled possibility, and saying so plainly, rather than implying an ongoing campaign we cannot evidence.

And we are still not putting the census in our blocklists. Those addresses are victims. An exposure map is a list of people who need to be told something, not a list of people to block.

What is not uncertain is the first link, and it is the one you control. The port is either reachable from the internet or it is not, and you can check that in about a minute — before anyone has to find out what the other three links are worth.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com