The exposure of more than 24,000 server BMCs leaking password hashes highlights a serious and long-running weakness in how critical server-management interfaces are deployed and protected.

A Baseboard Management Controller, or BMC, is a dedicated management component built into many servers. It allows administrators to monitor hardware, power systems on or off, access remote console functions, mount virtual media, inspect sensors, and manage the server even when the main operating system is down. In simple terms, it is the server’s out-of-band control plane.

That is exactly why exposed BMCs are so dangerous. A BMC is not just another web interface. It can provide deep administrative control over the physical server. If attackers compromise it, they may be able to restart systems, access console sessions, change boot behavior, mount malicious images, manipulate firmware, disrupt operations, or gain a powerful foothold below the operating system.

The reported exposure involves CVE-2013-4786, a decades-old weakness affecting IPMI-style authentication behavior. The issue can allow unauthenticated attackers to retrieve password-derived authentication hashes from exposed BMC interfaces before logging in. Those hashes can then be taken offline and attacked using password-cracking tools.

This is a major problem because offline cracking gives attackers time and flexibility. They can test large password dictionaries, leaked password lists, rules, mutations, and GPU-accelerated cracking techniques without triggering normal login-rate limits on the target device. A strong password may resist cracking. A weak, reused, predictable, or vendor-default password may fall quickly.

The age of the flaw is part of the story. A vulnerability from years ago should not still be exposing tens of thousands of server-management interfaces on the public internet. Yet here we are, because apparently infrastructure risk ages like a cursed family heirloom: passed down, ignored, and eventually discovered by someone with a scanner.

The fact that so many BMCs remain exposed shows that many organizations still treat management interfaces as ordinary services instead of privileged control planes. That is dangerous. BMCs should never be directly reachable from the public internet. They should be isolated on dedicated management networks, reachable only through VPN, bastion hosts, jump servers, or tightly controlled administrative paths.

The risk is especially serious for data centers, hosting providers, cloud providers, GPU providers, managed service providers, research environments, universities, enterprise server rooms, and organizations running remote infrastructure. A compromised BMC can impact availability, confidentiality, integrity, and recovery.

For attackers, BMC access is valuable because it sits below normal endpoint protection. Security agents inside the operating system may not see BMC-level activity. A server can look clean from the OS while the management controller remains compromised or misconfigured. That is a lovely little nightmare, because defenders enjoy nothing more than having to secure a computer inside the computer.

Organizations should immediately identify all BMC, IPMI, iDRAC, iLO, IMM, Redfish, and vendor-management interfaces in their environment. This inventory should include production systems, disaster-recovery systems, lab servers, hosting nodes, GPU clusters, backup servers, storage appliances, and old hardware that still has a live management port.

Internet exposure should be removed immediately. BMC interfaces should not be accessible from untrusted networks. Firewall rules should restrict access to known management stations and trusted administrative networks only. If remote access is required, it should be through a secure VPN or zero-trust access path with strong authentication and logging.

Administrators should disable IPMI over LAN where it is not required. If out-of-band management is needed, modern and secure configurations should be used. Legacy authentication modes, default accounts, weak ciphers, and unnecessary protocols should be disabled.

Passwords must be reviewed and rotated. Any BMC that may have exposed a password hash should be treated as potentially compromised, especially if the password is weak, reused, or old. BMC passwords should be unique, long, randomly generated, and stored in a secure password vault.

Default credentials should be eliminated. Shared administrator passwords across many BMCs should also be eliminated. If one hash is cracked and the same password is reused across hundreds of servers, one exposed device can become access to an entire fleet. Efficient for attackers, catastrophic for everyone else. The usual arrangement.

Organizations should also review whether BMC credentials overlap with operating-system, domain, hypervisor, storage, network, or cloud credentials. Reuse across management planes is extremely dangerous. A cracked BMC password should not become access to Active Directory, VMware, Linux root, backup consoles, or network devices.

Firmware updates are important. BMC firmware should be kept current according to vendor guidance. Many organizations patch operating systems but ignore management-controller firmware for years. That leaves critical out-of-band interfaces running old code with known weaknesses.

Security teams should scan internal and external address ranges for exposed BMC services. This includes IPMI UDP 623, web interfaces, Redfish APIs, vendor-specific management ports, SSH, and remote console services. External scanning should confirm that no BMC interface is reachable from the internet.

Logging and monitoring should be improved. BMC access logs should be collected where possible and reviewed for failed logins, unusual source IPs, configuration changes, firmware updates, power events, remote console sessions, virtual media mounts, and new user creation. These logs are often neglected, which attackers surely appreciate.

Network segmentation is essential. Management networks should be separated from production traffic, user networks, guest networks, and the public internet. Only administrator jump hosts should reach BMC interfaces. BMCs should not be able to initiate broad outbound traffic unless explicitly required.

Organizations should also monitor for suspicious activity after possible exposure. This includes unexpected server reboots, altered boot order, unknown virtual media mounts, firmware changes, new BMC users, changes to network settings, remote KVM usage, and failed authentication spikes.

For high-risk environments, administrators should consider resetting BMCs to known-good configuration, rotating all credentials, updating firmware, disabling unused features, and validating configuration against a hardened baseline.

Cloud and hosting providers should pay special attention. Exposed BMCs can affect many tenants or customer workloads. A server-management compromise in a hosting environment can create large-scale risk, including access to customer data, service disruption, infrastructure tampering, and trust damage.

This issue also reinforces the importance of treating hardware-management interfaces as part of the security perimeter. Firewalls, VPNs, identity providers, hypervisors, backup systems, and BMCs are all control-plane systems. Compromise of any one of them can have outsized consequences.

The key lesson is that password hashes are still sensitive data. Even if the plaintext password is not immediately exposed, a leaked hash can become a password later if attackers crack it offline. Strong password hashing and restricted exposure matter, but the better answer is not exposing the authentication material to unauthenticated users in the first place.

Organizations should remove BMCs from the public internet, update firmware, disable legacy IPMI features where possible, rotate credentials, enforce unique strong passwords, segment management networks, and monitor BMC activity.

A BMC is designed to control the server when everything else is unavailable. That power is useful for administrators and extremely attractive to attackers. Leaving it exposed to the internet with a known hash-leak weakness is not remote management. It is remote opportunity.

More than 24,000 internet-exposed servers are leaking authentication password hashes due to a 20-year-old vulnerability in their Baseboard Management Controller (BMC) interface. [...]

Source: Over 24,000 exposed server BMCs leak password hash via decades-old flaw via Bleeping Computer — published 28 Jul 2026.