86,000 Server BMCs Sit Exposed, Half Critically Flawed

Underneath every enterprise server is a second computer you probably do not patch. It has its own processor, its own firmware, its own network port, and it stays powered when the machine is off. It can mount virtual media, reflash the BIOS, and watch the console. It is called a baseboard management controller, and on August 6 at Black Hat, HD Moore presented a scan showing that 86,000 of them are reachable from the open internet and 54% carry at least one critical vulnerability.

Moore created Metasploit and did the foundational IPMI research in 2013. His talk, "Lights Out: BMCs Are Still Broken and Now We Have the Receipts," is a thirteen-year follow-up, and the receipts are that almost nothing was fixed. 75,000 of those exposed controllers are still vulnerable to CVE-2013-4786, an IPMI 2.0 flaw that hands an unauthenticated attacker a password hash to crack offline, before login.

RelatedOne Open API Exposed 676,000 Eicher Trucks to Takeover

Why is a BMC worth more to an attacker than root?

Because it survives everything you would do about a breach. Reinstall the OS and the BMC is untouched. Pull the power and it keeps running on standby. Your EDR agent runs inside the host operating system, which the BMC can reboot, reimage or silently observe, and which has no reliable way to inspect the controller beneath it. An attacker who owns the BMC owns the machine in a way that outlives your incident response.

Moore's phrasing was that the result is a pervasive, under-monitored, under-patched parallel attack surface. The word doing the work there is "parallel." This is not a gap in your patching. It is a second fleet, roughly the size of your first fleet, that most organizations have never enumerated at all.

What did the scan actually find?

Two populations, and the internal one is the more uncomfortable number. Externally, 86,000-plus BMCs had management services reachable from the public internet, with 54% carrying at least one critical vulnerability. Inside corporate networks, runZero scanned 126,761 BMCs and found 29% with one or more critical flaws. That internal figure matters because the standard mitigation advice, keep them off the internet, only moves the problem behind a perimeter that a phished laptop already sits inside.

The flaw classes go well past the 2013 IPMI issues. Moore's team documented predictable session identifiers derived from counters and clock values, pre-authentication memory corruption in HPE iLO's SSH management service, unsigned or modifiable firmware on Supermicro, H3C and Dell hardware, and hardcoded secrets extractable straight out of firmware images from Supermicro, OpenBMC, Huawei and Dell. Individual CVE identifiers are being held until coordinated disclosure concludes, which is the correct call and also means the patch wave is still ahead of us.

Which hardware is affected?

That list is effectively "servers." If you run rack hardware from anyone, you are on it.

1. 2013Dan Farmer and HD Moore publish the original IPMI research Cipher Zero auth bypass, RAKP hash disclosure
2. 2013CVE-2013-4786 assigned pre-login password hash disclosure, offline cracking
3. Jul 202624,650 exposed BMCs found leaking IPMI hashes the first public sign the problem never shrank
4. Aug 6 2026"Lights Out" presented at Black Hat 86,000 exposed, 54% critical; OOBscan released
5. DEF CON 34Companion talk: "Out-of-Band, Out of Mind, Out of Control" individual CVEs to follow as disclosure closes

Why has this survived thirteen years?

Ownership, mostly. The BMC belongs to nobody. Server hardware is bought by infrastructure, racked by data centre operations, patched by whoever owns the OS image, and the controller sits in the seam between all three. It has no package manager, no agent, and no entry in your vulnerability scanner unless someone deliberately added the management subnet to scope. Firmware updates usually require a maintenance window on a production host, which means they get deferred, and deferred, and then the server is decommissioned still running its shipping firmware.

The economics do not help either. A BMC flaw is not a shiny remote-code-execution bug in a popular web framework; it is an unglamorous firmware problem on hardware whose vendor has already booked the revenue. Farmer and Moore said all of this in 2013. The scan is what happens when nobody is scored on the answer.

RelatedZimbra Patches Stored-XSS RCE in Classic Web Client

What to do this week

Start by finding out how many you have, because that number is usually wrong. Moore's team released OOBscan, an open-source scanner built for exactly this, and running it against your own ranges is a one-afternoon job that produces a number your leadership has never seen. Then check whether any BMC answers on UDP 623 from outside your network, which is the single question that separates "a real problem" from "an urgent one."

After that: put every management interface on an isolated VLAN reachable only from a jump host, replace default and vendor-shipped credentials, and add the management subnet to your vulnerability scanning scope permanently rather than as a one-off. Log authentication attempts against the controllers. None of this is new advice. That is rather the point.

Our take

The striking thing is not that BMCs are insecure. It is that the exact flaws were published in 2013, with proof of concept, by a widely-read researcher, and 87% of internet-facing controllers still have them. Security research assumes that disclosure creates pressure and pressure creates patches. For firmware on hardware that has already been sold, that chain is broken at every link.

Treat this as an asset inventory problem before treating it as a patching problem. Most organizations reading this do not know their BMC count within an order of magnitude, and you cannot defend a fleet you have not counted. Run the scanner, get the number, and decide what it is worth to you. The alternative is finding out from someone else.

Original analysis by GenZTech. Scan data and vendor list from runZero's published research, presented at Black Hat 2026.