There is another computer inside your server, and 36,872 of them are on the internet

When you power off a server, the server does not go off. Inside, a small computer stays awake with its own processor, its own firmware, its own IP address and its own password. It is called a BMC, and it is the most privileged component in the rack: it powers on, powers off, mounts an ISO and hands you the screen as if you were standing in front of the machine. It is also, almost always, the one component nobody has logged into since installation day. On 29 July the count was published: 36,872 of those computers are listening on the internet, and 24,650 hand material derived from the account password to anyone who asks, before logging in.

We run our own hardware across several datacenters — Proxmox clusters with Ceph, our own network — and we get paid to maintain other people's infrastructure, so we do not read this count as a headline curiosity. We read it as a task list that has had no owner for years. Numbers first, then the uncomfortable part: this does not get closed with a patch.

What exactly is exposed

The BMC (Baseboard Management Controller) is the management processor built into rack servers. Depending on the vendor it is called iLO, iDRAC, IPMI or simply "management", and you talk to it through a protocol called IPMI on port 623/UDP. Its whole point is that it works out of band: it does not depend on the operating system, nor on the operating system booting, nor on the server being powered on. As long as the power supply has current, the BMC is alive.

Access to a BMC does not mean "administering a server". It means doing everything someone standing in front of the rack with a keyboard, a screen and a USB stick could do: power off, power on, enter the BIOS, mount a remote image and boot from it. That is why we dislike the term "management interface": it is a remote physical console, and whoever controls it does not even need to touch your operating system. Reinstalling the server does not evict them either.

The numbers behind the count

The scan is dated 6 May 2026 and looks for anything answering on 623/UDP from the internet. It was published on 28 and 29 July. As is:

Adding up the two published crackable categories — empty account and named account — gives 8,580 controllers whose password is within reach of a wordlist. The exact sum is ours; the coverage of the research puts it as "about one-third". It deserves a careful reading: it is one in three of the 24,650 that leak material. It is not 100%, and saying so matters. But one in three, across a sample of 36,872 physical machines that hold something up, is an enormous number.

By geography, more than 14,000 sit in the United States, with concentrations in Germany, China, the Netherlands and the UK. Spain not making the headline means nothing: the scan measures what is exposed, not where the problem is.

Why a patch will not fix this

The identifier is CVE-2013-4786, with a CVSS v3 score of 7.5. The identifier dates from 2013, but the behaviour comes from the IPMI 2.0 specification, published in 2004: during the session establishment exchange, the controller replies with an HMAC-SHA1 computed over the account password and session values the requester already holds. In other words: the protocol is designed to hand that over. It is not one vendor's implementation bug.

Dell said it with a clarity we appreciate: there is no patch, and this is "an inherent problem with the specification for IPMI v2.0". Supermicro acknowledged the scenario is feasible and recommended rotating passwords and isolating management on VLANs with access lists, while announcing it will review its default password policy in future hardware revisions. Neither promised a firmware update that closes it, because none can exist.

Here is the part we find most interesting, and the one that explains the 36,872: the industry has learned to manage vulnerabilities as things you patch. The advisory arrives, joins the queue, gets applied, the ticket closes. A flaw with no patch does not fit that circuit: there is nothing to install, so there is nothing to close, so it stays open for twenty-two years. The mitigation is not a version, it is a topology decision — and topology decisions do not get made by a security bulletin.

A unique factory password does not save you either

More than half of the controllers that answered were Supermicro, and Supermicro does something that is right: since November 2019 — to comply with California's SB-327 — it stopped shipping boards with the ADMIN/ADMIN shared across the whole catalogue and assigns each unit a different password, printed on a chassis label. If your board predates that, you are still on the shared one, and there nothing needs cracking. For the rest, the problem is the format. It is exactly ten uppercase letters, which is a space of 26¹⁰ ≈ 141 trillion combinations. That sounds enormous until someone measures it: with an eight-GPU server running Hashcat, exhausting that space takes about one hour.

On HPE iLO the factory format is shorter — eight characters of uppercase letters and digits, 36⁸ ≈ 2.8 trillion — and there the published timings stop being reassuring at all: around one day on an Apple M3, and roughly 32 seconds per response on a box with eight RTX 6000 PRO cards. And we are not talking about last decade's hardware: the tested systems include a 2023 Supermicro X13DEM board.

None of this will show up in your alerts

This is what lets the problem age in silence. The request that returns the hash is not a failed login attempt: it is a legitimate phase of the protocol, so there is nothing to count on a "rejected authentications" dashboard. Cracking happens afterwards, on the attacker's machine, without touching you again. And your EDR runs inside the operating system, while the BMC is not the operating system: it sits underneath it. When the intruder comes back, they come back with valid credentials.

The pattern is familiar because we have written it twice this month with different protagonists: the network orchestrator deployed facing the internet because that is more convenient and the management console nobody counted as attack surface. It is always the management plane, and always for the same reason: it gets set up in a hurry on deployment day and documented with a "we will close it later".

The figure that worries us most is not 36,872

It is 60. During the observation months, around sixty new IPs appeared every day exposing IPMI. Sixty a day is not an inherited inventory of forgotten 2011 servers: it is a flow. It is hardware someone racked this week, with its management cable plugged into the first free port on the switch — the one carrying the data VLAN — because it was Friday and the thing had to boot.

The component missing from your maintenance contract

Take any maintenance contract and look for the BMC. You will find operating system patches, backups, antivirus, monitoring, maybe storage array and switch firmware. Management controller firmware and the rotation of its credentials are usually on no line at all. Not out of bad faith: because the BMC belongs to nobody. The systems person assumes it is "a hardware thing", the network person sees just another IP, and whoever racked the server left the same day.

Four questions to ask your provider this week. Or to ask yourself, if the provider is you:

• How many BMCs do we have and which VLAN are they on? If the answer takes more than five minutes, you already have your first finding.
• Are any still using the password from the sticker? You now know what that sticker is worth: between 32 seconds and one hour.
• What firmware version are they running? Not for this flaw, which is unpatchable, but for the others — the ones in the controller's own web interface, which do get patched and appear every few months.
• Who would notice if someone got in? And with what signal, given there will be no failed login to alert on.

And the honesty this deserves: if you own no hardware, this is not about you. If everything you run is virtual machines in a public cloud, the BMC belongs to the provider and it is their problem. But if you have servers in a rack — owned or rented — the BMC is yours even when the rack is not; in colocation the cage belongs to someone else and the remote console is still your responsibility. It is exactly the kind of invisible cost we discussed in the five-year math of owning hardware versus cloud: your own hardware prices well, but it brings tasks that never show up on a cloud invoice because someone else does them.

What to do today, in this order

• 1. Check whether you are on the list. From outside your network, against your own public ranges: nmap -sU -p 623 --script ipmi-version YOUR.RANGE/24. If something answers, that something is a computer with permission to power your hardware on and off, and anyone can see it.
• 2. Close 623/UDP at the edge — along with the controller's web interface and its KVM, which do not live on the same port. Honest caveat: closing the port does not fix the protocol, it only takes it out of the internet's reach. Anyone already inside your network still gets the same gift.
• 3. Replace every factory password with a long, random one from a password manager. Not so it stays secret — the hash goes out regardless — but so cracking it does not fit anyone's budget.
• 4. Turn off the legacy options: IPMI 1.5, cipher suite 0, anonymous accounts and NONE authentication. They are options from another era still there because nobody switched them off.
• 5. A separate management network — genuinely separate. Dedicated VLAN, no route to the internet, and access only over VPN from admin workstations. We do it with WireGuard and keep the inventory in NetBox as a single source of truth: knowing how many BMCs exist and which VLAN each one is on is half the control.
• 6. Use Redfish over TLS on hardware that supports it, instead of IPMI. With the researchers' own warning attached: neither Redfish nor IPMI should face the internet directly.

None of those six points requires buying anything. They require someone to own the task, which is exactly what has been missing all along.

What this count really says

There is no villain vendor here and no new attack campaign. There is a 2004 protocol doing what it documented it would do, a 2013 identifier nobody could close because there was nothing to install, and 36,872 machines whose owner never wrote down that the small computer inside also counts. The headline says "twenty-year-old vulnerability". We read it differently: twenty-two years of unassigned work.

If you only do one thing from this post this week, make it the point-1 scan against your own ranges. It takes less time than reading it.

Sources (verified): the 6 May 2026 scan, the 36,872 IPMI services on 623/UDP, the 24,650 returning password-derived material, the 6,240 with empty usernames, the 2,340 with dictionary accounts, the ~60 new IPs per day, the Supermicro and HPE factory password formats with their cracking times (one hour on eight GPUs; ~32 seconds on eight RTX 6000 PRO cards; ~one day on an Apple M3), the 2023 X13DEM board, the 0.3 BTC ransom note on an iLO 4 and the recommended mitigations — Lava research, "How We Hacked Thousands of Data Centers in Minutes Using a 20-Year-Old Vulnerability" (29 July 2026). Coverage, geographic distribution (over 14,000 in the US), CVSS 7.5 and vendor statements — Dell: "there is no patch", "an inherent problem with the specification for IPMI v2.0"; Supermicro on credential rotation, VLANs and a future password policy — in The Hacker News and Help Net Security (28 July 2026). Supermicro unique per-unit password since November 2019 — ten uppercase letters printed on a chassis label, replacing the shared ADMIN/ADMIN, to comply with California SB-327: official Supermicro page on the BMC unique password. Flaw identifier and description: CVE-2013-4786. The sum of 8,580 crackable controllers (6,240 + 2,340) is our arithmetic on their published figures; the reading of why an unpatchable flaw ages for twenty-two years, the order of the six steps and the four questions for your provider are ours. Image: rear of a rack at the NERSC data center (Wikimedia Commons, public domain).