HD Moore, founder of runZero, announced at Black Hat USA 2026 on August 5, 2026, more than 12 new vulnerabilities and large-scale scan results concerning BMCs remaining in enterprise servers. More than 86,000 BMCs had management services exposed to the internet, and over 54% of them were found to have at least one critical vulnerability. A BMC can operate a server even when its OS is down. If compromised, it becomes a management pathway that bypasses OS-side defenses. What makes this warning particularly serious is that an IPMI issue disclosed 13 years ago still remains in up to 75,000 devices, and new authentication bypass and session hijacking flaws can be chained onto it.
86,000 Management Ports Exposed to the Internet
A BMC (Baseboard Management Controller) is a maintenance computer built into a server's motherboard. It has its own firmware, network stack, and IP address, and administrators use it to power-cycle machines, apply updates, and reinstall the OS. Using browser-based KVM and virtual media, they can operate the console and connected storage media without being physically present at the machine.
This authority does not depend on whether the host OS is running. If an attacker gains administrative control over a BMC, they can manipulate the device before the OS even boots, leave modifications persisting in firmware, and reach into the OS again after it is reinstalled. This falls outside the scope monitored by EDR running on the OS. A pathway that supports maintenance thus becomes a pathway that supports attacks at the same depth.
In the external scan Moore presented to Ars Technica, more than 86,000 BMCs had exposed management services, and over 54% had one or more critical vulnerabilities. Among 126,761 devices examined within enterprise networks, nearly 29% met the same criteria. However, because the external and internal populations differ, this gap cannot be directly compared as evidence of network segmentation's effectiveness. The raw data, including the scan period and deduplication methodology, has not been published either, so these figures should be read as findings disclosed by Moore.
Why the 13-Year-Old RAKP Issue Remains an Entry Point
CVE-2013-4786, said to affect up to 75,000 devices, stems from RAKP authentication in IPMI 2.0. Before authentication is completed, the BMC includes an HMAC computed from the password in its response. An attacker who captures this over the network can take it back to their own environment and check it against candidate passwords offline. Unlike online attempts, this is unaffected by account lockouts and doesn't leave a trail of failed login attempts on the BMC side.
NVD disclosed this issue on July 8, 2013, and rated it 7.5 (High) on the CVSS v3.0 base score. Because it is rooted in the protocol handshake itself, some products remain affected even after firmware updates, as long as IPMI over LAN is enabled. HPE now disables IPMI by default on current iLO 7 and advises leaving it disabled if unused, recommending the iLO RESTful API as an alternative.
In environments with short default credentials, a leaked hash reaches the administrator password even faster. According to Moore, even factory-randomized credentials sometimes have a narrow search space; the schemes used by HPE, Supermicro, and Dell were examined in the research. Therefore, simply confirming that credentials have been "changed from the default" is insufficient. Administrators must verify whether they have changed to sufficiently long and unique usernames and passwords, and whether IPMI itself can be disabled.
Reaching Administrative Control Through Chained Flaws, Not Single Bugs
The new issues reported this time do not fall into a single category of implementation error. They include a flaw that obtains a limited connection by reordering IPMI authentication messages, an implementation that fails to enforce negotiated encryption and integrity on packets during a session, and session IDs that can be guessed from counters or timestamps. On HPE iLO, a pre-authentication memory corruption issue was also found, stemming from length validation in the management SSH service. Moore explained that this could serve as a pathway to run attacker code on the BMC itself.
In other product families, issues involved unsigned firmware, modifiable verification settings, and keys or constants that could be recovered from publicly available firmware. Even flaws that are only exploitable post-authentication can have their prerequisites undermined when combined with RAKP hash leakage, weak default credentials, or pre-authentication weaknesses. These must be evaluated as a chain: gaining a foothold through limited access, hijacking a session, obtaining administrative control, and leaving behind modified firmware.
Exact counts of new vulnerabilities, affected versions, and fixes are not yet fully available. The products examined include HPE, Supermicro, and Avocent. Huawei, Lenovo, and Dell were also mentioned, but not all their products share the same flaws. Additionally, no evidence has been presented that the new vulnerabilities Moore reported this time have been exploited in actual attacks.
On the other hand, it has been confirmed through separate cases that BMCs are real-world attack targets. In June 2025, the US CISA added CVE-2024-54085, an authentication bypass in AMI MegaRAC SPx, to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation. AMI rated this vulnerability 10.0 on CVSS 4.0 and identified SPx 12.7 and later, as well as SPx 13.5, as the fixed versions. While this does not substantiate exploitation of the new flaws reported here, it makes concrete the premise that BMC management surfaces are targeted by attackers.
What OOBscan Covers, and What Gaps Remain
runZero released OOBscan, the tool used in this research, under the BSD 2-Clause license. The tool examines IPMI, Redfish, and iLO to identify devices and vendors. It also covers management surfaces accessed via HTTP and TLS, as well as iDRAC, running both device-specific checks and cross-vendor checks. Offline analysis of hashes leaked via RAKP, default credentials, and known vulnerable firmware can all be checked in a single scan.
However, the published version is a pre-release. Detailed checks for vulnerabilities still undergoing vendor notification and coordinated disclosure are not yet included. Even if OOBscan detects zero issues, this cannot be taken to mean the problems reported here don't exist. It is best suited for taking inventory of BMCs as assets and separately verifying external exposure, IPMI enablement status, firmware versions, and the persistence of default credentials.
Moore recommends setting long, unique usernames and complex passwords, and disabling IPMI and KCS where not needed. Since KCS provides a pathway from the host side to the BMC, if it cannot be disabled, that access route should also be restricted. Furthermore, multiple BMCs should not be grouped onto a shared VLAN; each management interface should be segregated. Identifying the pathways necessary for operations first, then blocking the rest, allows attack surface reduction without halting server maintenance.
As vendor coordinated disclosures progress, the list of affected products, fixes, and OOBscan's inspection items will grow. Administrators have no reason to wait for that. Eliminating externally reachable BMCs, disabling unnecessary IPMI, and confirming whether remaining management pathways are properly segregated—these are the baseline defenses that can be verified right now.