Thousands of Internet-Connected Servers Backdoored by Buggy Motherboard Controllers
Baseboard management controllers — those unassuming microchips embedded on nearly every enterprise server motherboard — are sitting wide open to remote takeover. New research presented at Black Hat 2026 reveals that thousands of servers sold by the world's biggest hardware manufacturers ship with vulnerable BMC firmware, and attackers can exploit these flaws to install remote backdoors without authentication.
The findings come from HD Moore, founder and CEO of runZero, who laid out his research at the Black Hat security conference in Las Vegas. His team found more than 86,000 BMCs exposed to the public Internet, with 54% harboring at least one critical vulnerability. Even more alarming: 29% of BMCs inside corporate networks also showed critical flaws. These aren't edge-case misconfigurations. They're systemic failures baked into firmware shipped by vendors including HPE, Dell, Lenovo, Supermicro, Asus, Fujitsu, and others — firmware that still hasn't been patched at scale.
The Redfish Authentication Bypass: CVE-2024-54085
At the center of this crisis is CVE-2024-54085, a CVSS 10-rated vulnerability in American Megatrends' (AMI) MegaRAC BMC firmware. Discovered by researchers at Eclypsium, this flaw allows unauthenticated remote control of servers by bypassing authentication entirely.
The vulnerability stems from a fundamental design flaw: BMC systems use the server's IP address as an authentication credential. When a Redfish management console receives a request, it checks HTTP headers — specifically X-Server-Addr or Host — to determine whether the request comes from the internal "host interface." Requests from trusted internal addresses are automatically treated as authenticated.
Here's how an attacker exploits it. BMC chips use a link-local IP address (typically 169.254.0.17) to communicate between the BMC chip and the host server. By crafting a specially formatted X-Server-Addr header, something like 169.254.0.17:, an attacker can trick the BMC into treating their external request as though it came from the internal host interface. The BMC's authentication logic, which relies on a regular expression to extract text before the first colon character, happily accepts the spoofed address.
Once past authentication, the attacker gains full access to the Redfish management API. They can create privileged service accounts, access admin web interfaces, reboot servers, modify firmware, install ransomware, or even cause physical damage through over-voltage attacks. The proof-of-concept exploit was verified against HPE Cray XD670, Asus RS720A-E11-RS24U, and ASRockRack systems.
AMI released patches on March 11, 2025. HPE and Lenovo issued updates for affected products. But dozens of other vendors, including Gigabyte, NVIDIA, Tyan, and Supermicro, remain in the dark, with no available patches. BMC firmware sits on a dedicated chip on the motherboard, meaning updating it requires specialized flashing utilities, system reboots, and often extended downtime. Many administrators simply haven't gotten to it.
A Decade of Unpatched IPMI Vulnerabilities
While CVE-2024-54085 grabs headlines, Moore's research uncovered a much broader landscape of BMC weaknesses, many of which have existed since at least 2013 and remain unaddressed.
The vulnerabilities span multiple layers of the BMC stack:
IPMI authentication flaws. Several systems allow attackers to manipulate the order of authentication messages to bypass checks and gain limited foothold. Affected products include HPE iLO, Supermicro, OpenBMC, and OpenBMC-derived systems from H3C and NVIDIA. From that foothold, additional vulnerabilities can be chained together to achieve full control.
Session security gaps. IPMI doesn't always enforce integrity and encryption during sessions. "The device decides whether to authenticate and decrypt each packet from that attacker's own header, and not from the algorithms the session negotiated, so an unsigned, unencrypted command is accepted on a secured session," Moore explained. He developed a proof-of-concept chaining otherwise-unexploitable issues into full sessions, affecting HPE, Supermicro, and legacy Intel systems.
Predictable session IDs. Some implementations generate session tokens based on simple counters or clock values rather than strong random values. An attacker can guess another user's active BMC session and hijack it through both IPMI and browser-based KVM consoles. The two most serious vulnerabilities of this type affect Supermicro systems.
Pre-authentication memory corruption. In HPE iLO systems, a length-validation flaw in the management SSH service can be exploited before authentication, executing attacker-controlled code directly on the BMC. This provides a direct path to remote code execution.
Firmware integrity issues. In some systems, firmware is unsigned or can be modified by attackers, while configuration integrity checks aren't enforced. An authenticated administrator account could be abused to install persistent implants or replace verification keys. Supermicro, H3C, and Dell are affected.
Exposed secrets in firmware. Keys and cryptographic constants embedded in publicly available firmware images can be extracted and reused as valid credentials. Moore identified this pattern in devices from Supermicro, OpenBMC, Huawei, and Dell.
Weak password practices. Many BMCs still rely on default or factory-generated credentials. CVE-2013-4786, a flaw in IPMI 2.0's authentication protocol, allows attackers to obtain password hashes and perform offline cracking attacks. Even when vendors randomize passwords before shipment, the available keyspaces can be too small. Moore found that HPE uses "eight digits or alphanum," which he called the weakest approach. Supermicro and Dell use somewhat longer default credentials that slow attacks but don't prevent them, extending password recovery from hours to days depending on computing power.
"Many of the newly discovered vulnerabilities require authentication to exploit, but that barrier can often be bypassed by chaining them with pre-authentication flaws," Moore noted. "In other cases, attackers who gain limited access can install older, vulnerable, or deliberately backdoored firmware on the BMC and then use control of the operating system to further modify the controller."
The Scale of Exposure
Moore conducted two broad scans to measure the scope of the problem. His external scan identified more than 86,000 BMCs with management services exposed to the public Internet. More than half, 54%, had at least one critical vulnerability. As many as 75,000 remained vulnerable to CVE-2013-4786 alone, the IPMI 2.0 authentication flaw allowing offline password cracking.
His internal corporate network scan of 126,761 BMCs found that nearly 29% contained one or more critical vulnerabilities. These are systems behind firewalls, in private data centers, assumed to be safe from external attackers. They're not.
"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 in an email ahead of his talk.
Defending Against BMC Attacks
For organizations trying to understand their exposure, Moore released an open-source scanner called OOBscan, which allows administrators to scan entire server fleets for the BMC weaknesses he documented.
His recommendations for hardening BMCs are practical, if unglamorous:
- Use long, unique usernames and complex passwords (20+ characters, no dictionary words)
- Disable IPMI and KCS (Keyboard Controller Style) interfaces when not needed
- Block host-side access to the BMC entirely
- Isolate each BMC network interface on its own dedicated VLAN, never share a management VLAN across multiple controllers
- Keep firmware updated when vendors release patches, understanding that BMC updates require specialized flashing utilities and system downtime
Moore's conclusion was blunt: "BMCs are still an underrated risk. This work points to the ecosystem being well behind the curve in terms of code quality and architecture."
The implications for AI infrastructure are particularly severe. In GPU clusters and AI training environments where multiple tenants share physical hardware through virtualization or GPU partitioning, a single compromised BMC could potentially expose several customer workloads simultaneously. The risk isn't just password theft or server reboot, it's firmware tampering, persistent implants, and physical damage through over-voltage attacks.
Securing the foundation of your server infrastructure isn't optional anymore. By shutting down public BMC exposures, isolating management networks, and continuously scanning for these vulnerabilities, you strip away one of the most dangerous attack vectors available to modern threat actors.
