BlackTree Security · Infrastructure · Automation · AI

The Server Was Off. Its Management Processor Was Still Reachable.

Security researchers have documented a broad set of weaknesses in the management processors built into enterprise servers. The findings span OpenBMC, Supermicro IPMI, HPE iLO, Dell iDRAC, AMI MegaRAC, Raritan, H3C HDM and Fujitsu systems.

The research matters because a baseboard management controller, or BMC, is not just another service on the host. It runs independently of the main operating system, has deep control over the hardware and often remains reachable when the server itself is powered off.

The control plane below the operating system

Administrators use BMC platforms for remote console access, firmware updates, power cycling and hardware monitoring. Those capabilities make remote recovery possible, but they also give the management processor a privileged position that endpoint security software on the host cannot fully observe or contain.

In its Lights Out research, runZero said the issues it found could enable unauthorised control, disruption, security-control bypass, lateral movement and persistent access. The affected product range shows that the risk is systemic rather than tied to one server brand.

The company presented the work at Black Hat USA 2026. Detailed vulnerability records and CVE assignments were still being coordinated when the research was published, so defenders did not yet have a single patch list to follow.

Why a powered-down host can still be exposed

A server can be shut down while its management controller continues to receive standby power and accept network connections. That is a feature, because operators need to start or repair a failed machine remotely. It is also a trust boundary that ordinary vulnerability scans and host inventories can overlook.

An attacker who compromises the BMC may gain a path around controls enforced by the host operating system. Reinstalling that operating system, rotating local credentials or replacing an endpoint agent may not remove access anchored in the management plane.

The management interface can also bridge otherwise separated environments. A BMC may have a dedicated network port, share a physical interface with the host, or be reachable through a management VLAN. Those architectural differences need to be discovered rather than assumed.

There is no universal patch

runZero did not publish a universal remediation because the research covers multiple codebases and vendors. It advised organisations to follow each supplier’s security notices and firmware releases while reducing exposure immediately.

  • Inventory every management processor. Record the server, BMC model, firmware version, address, exposure path and owner.
  • Remove internet exposure. Place BMC interfaces on a dedicated management network reachable only through controlled administrative paths.
  • Restrict source addresses. Limit access to trusted jump hosts, VPN ranges and management systems.
  • Separate credentials. Do not reuse directory or host passwords, and replace default accounts where the platform allows it.
  • Monitor the management plane. Collect authentication, configuration, firmware and network events independently of the host.
  • Track vendor advisories. The absence of a CVE in the initial research does not mean that a deployed product is unaffected.

Detection must survive a compromised host

Defenders should assume that host telemetry can become incomplete once the layer beneath it is compromised. Network monitoring for unusual BMC access, configuration exports and remote-console use can provide evidence that the operating system cannot.

Asset discovery is equally important. Unmanaged BMC addresses can persist for years because they sit outside ordinary server administration. Scanning the management ranges and reconciling results with hardware inventories is a practical first step.

The BlackTree view

BMC security is easy to defer because the devices look like maintenance infrastructure. Their real role is closer to a hardware root administrator. They can control power, console and firmware outside the operating system’s security boundary.

The immediate lesson is architectural. Organisations should treat the server management plane as a separate high-privilege environment with its own inventory, access policy, logging and incident-response procedure. If a recovery plan begins at the operating system, it begins one layer too high.

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *