86,000 exposed BMCs: your server's hidden second computer
New Black Hat research found critical bugs in baseboard management controllers from HPE, Dell, Supermicro and more. Why this matters most if you buy used enterprise servers.
A baseboard management controller is the small computer bolted inside your server that can power the machine on, reinstall its operating system, and watch its console — and new research says tens of thousands of them are sitting on the public internet with critical bugs. Ars Technica's Dan Goodin wrote up the findings from a Black Hat talk this week.
My read is not "patch your BMC." It's that the BMC outranks everything you have secured above it, and almost nobody on a small team has ever logged into theirs.
🔍 The component that outranks your operating system
HD Moore, founder and CEO of runZero, presented more than a dozen new BMC vulnerabilities affecting HPE, Supermicro, Avocent, Huawei, Lenovo, Dell and others. Some of the weaknesses he warned about back in 2013 are still live.
The reason this matters more than a normal CVE is the position a BMC occupies. It runs its own OS firmware, its own network stack, and its own IP address, and it keeps working when the server is powered off or hung. That is the whole point of "lights out" management. It's also the whole problem.
Your security model probably assumes a hierarchy like this:
| Layer | Can it be reinstalled to recover? | Who audits it at your org? |
|---|---|---|
| Application | Yes, trivially | You |
| Container / runtime | Yes | You |
| Host OS | Yes, reinstall | You, occasionally |
| Firmware / BMC | Not by reinstalling the OS | Usually nobody |
Key takeaway: Every recovery step you know — reinstall the OS, swap the disks, restore from backup — happens above the BMC. If the BMC is owned, none of those steps clean the machine.
This isn't theoretical. The article points to ILObleed, a 2021 implant that infected HPE servers with wiper firmware. Administrators reinstalled operating systems and swapped hard drives, and it survived and re-triggered the disk wipe. The bug it used had been patched by HPE four years earlier. The patch existed. Nobody had applied it.
📊 The numbers make this a default state, not an edge case
Moore ran two scans, and I find the gap between them the most useful part of the whole study.
| Scan | BMCs found | Share with ≥1 critical vulnerability |
|---|---|---|
| Public internet | more than 86,000 exposing a management service | over 54% |
| Inside corporate networks | 126,761 | nearly 29% |
And one specific figure deserves its own line: as many as 75,000 of the internet-exposed devices were still vulnerable to CVE-2013-4786, a flaw in the IPMI 2.0 authentication protocol that lets an attacker pull a hash and crack administrator passwords offline. That CVE identifier tells you the year. Thirteen years, still shipping, still exposed.
"The end result is a pervasive, under-monitored, under-patched parallel attack surface that is both Internet-exposed and widespread inside corporate networks, and is much more exploitable than many folks realize," Moore wrote.
Note the direction of the two numbers. Even behind the firewall, roughly three in ten are critically vulnerable. So the fix is not only "get it off the public internet," though you should do that first.
🛠️ The used-server problem nobody prints on the invoice
Here's the angle I think matters most for readers in Sri Lanka, and it isn't in the original piece.
Almost nobody building a small rack here buys new enterprise hardware. You buy off-lease and refurbished — a Dell PowerEdge with an iDRAC, an HPE box with iLO, a Supermicro board with its own IPMI stack. It arrives from a local reseller, you rack it, you install Proxmox or Ubuntu, and you never touch the management interface because the reseller already set it up and you were sold a working machine.
Now line two of Moore's findings up against that purchase:
- Bug class 5 in his list: unsigned or attacker-controllable firmware, plus unenforced configuration integrity. An authenticated administrator can install a persistent implant, or replace the key used to verify firmware.
- Bug class 7: factory-randomised default credentials with small keyspaces, recoverable through offline cracking. Moore singles out HPE as the worst here (eight digits, or alphanumeric); Supermicro and Dell defaults are slightly longer, which buys you hours or days depending on the attacker's compute, not safety.
The previous owner of your used server was an authenticated administrator by definition. So was whoever refurbished it. Reinstalling the OS proves nothing about the firmware underneath, and the default sticker password may still be in place.
Treat a second-hand server's BMC as untrusted until you have reflashed its firmware yourself, reset it to factory defaults, and set your own credentials. That is not paranoia. It is the only part of that machine you cannot re-provision later.
⚡ What to actually do this week
Moore released an open source scanner called OOBscan for auditing a fleet against his catalogue of BMC bugs. Beyond running it, his defence list is short and unglamorous:
- Set long, unique usernames as well as long, complex passwords. The username matters because it's part of what makes the offline cracking attack cheap. Our password generator will produce both, and neither should be
ADMIN. - Disable IPMI wherever possible. Most small teams use the web console or the KVM, not the raw protocol. If you don't use it, turn it off.
- Disable KCS to block host-side access to the BMC. This is the one people miss: without it, compromising the OS gives an attacker a path down into the controller.
- Isolate each BMC NIC individually. Don't drop all of them on one shared management VLAN. If you're carving out per-device ranges, the IP subnet calculator does the arithmetic.
A fifth I'd add for anyone here on a single static IP from their ISP: check whether your router is port-forwarding anything to the BMC's address. That is the most common way a machine ends up in the 86,000.
💡 What this means for you
If you run one server in an office cupboard, or a lab box at university, or three nodes at a local colo, the honest position is that you have a second computer in each of them that you have never logged into, never patched, and cannot inspect from the OS.
That's not a moral failing. Moore's own conclusion is that the vendors are the ones behind:
"BMCs are still an underrated risk. This work points to the ecosystem being well behind the curve in terms of code quality and architecture."
But the practical consequence lands on you. Three things worth doing, in order of effort:
- Today: find out whether your BMC has a public IP. If it does, take it off.
- This month: change the credentials, and record the firmware version you're on.
- Before your next hardware purchase: decide whether "used enterprise server" fits your threat model, and price in a firmware reflash if it does.
For most small teams the answer will still be yes to used hardware. Buying new isn't realistic on a Sri Lankan budget, and cloud isn't always cheaper. Just stop treating the invoice as the moment ownership transferred. The BMC decides that, and it may not have been asked.