BMC attacks: How Cloudflare is locking down server management
Server management controllers have become a prime target for attackers. The specialized processors — known as Baseboard Management Controllers (BMCs) — sit on every server and provide out-of-band access for monitoring, firmware updates, and power control. Vulnerabilities like Pantsdown and USBAnywhere have shown how these interfaces can be abused, often because firmware updates are infrequent or overlooked entirely.
After being alerted by a trusted vendor to critical vulnerabilities in BMC software used in our fleet, we moved quickly to understand the exposure, patch affected systems, and validate that our broader security posture held up. Here is how we handled it and where we are taking BMC security next.
Why the BMC is a high-value target
The BMC is a small, specialized processor that manages a host system remotely. Because it has multiple direct connections to the host, it can monitor hardware, update BIOS firmware, and power cycle the machine. An attacker with control of the BMC can maintain persistence on a server even after the main operating system is reinstalled.
Access vectors can be local or remote. From the host side, an attacker can reach the BMC through PCI Express or the Low Pin Count (LPC) interface. The ASPEED AST2400 and AST2500 BMC chips include Advanced High-Performance Bus (AHB) bridges that allow arbitrary read and write access to the BMC's physical address space from the host — meaning malware running on the server can directly access BMC memory. These weaknesses can enable ransomware propagation, server bricking, and data theft.
What was vulnerable
The vulnerabilities impacted the QuantaGrid D52B cloud server. The affected interfaces, described in CVE-2019-6260, include the following on the AST2400 and AST2500:
- iLPC2AHB bridge Pt I and Pt II
- PCIe VGA P2A bridge
- DMA to arbitrary BMC memory via X-DMA
- UART-based SoC Debug interface
- LPC2AHB bridge
- PCIe BMC P2A bridge
- Watchdog setup
An attacker could exploit these interfaces to flash updated BMC firmware directly through SoCFlash, using either the inband LPC connection or the BMC debug UART serial console. That may look like a standard recovery path, but it amounts to abusing an open interface for flashing.
How we responded
Patched firmware
We contacted Quanta to confirm which firmware versions in our fleet were actually patched. Some already were; others were not. Quanta released an update, which we tested and deployed across affected BMCs.
Our Security and Infrastructure teams also proactively reached out to other manufacturers to confirm that their BMC patches addressed the same vulnerabilities and interfaces.
Keeping remote and local interfaces locked down
Our data centers use network segmentation to separate management traffic from everything else. Out-of-band networks are not internet-facing and are only reachable within their own data centers. Access to management networks requires multiple layers of defense, with connectivity restricted to jumphosts and authentication handled through our zero trust Cloudflare One service.
On the host side, applications are restricted in what they can invoke on the BMC. This limits what can be done from the host and still allows secure in-band firmware updates and userspace logging and monitoring.
Credential hygiene and auditing
Default BMC usernames and passwords are changed, and default accounts are disabled entirely so they can never be used. Static accounts are subject to regular password rotation.
All BMC activity is logged by default, covering:
- Authentication events (successful and unsuccessful)
- Authorization (user/service)
- Interfaces (SOL, CLI, UI)
- System status (power on/off, reboots)
- System changes (firmware updates, flashing methods)
These logs confirmed that no malicious activity had occurred.
Future direction: OpenBMC and a longer root of trust
We build systems with several original design manufacturers (ODMs) to our own specifications. The standard BMC chips usually ship with proprietary firmware that is opaque and hard for us and our ODMs to maintain. We are moving to OpenBMC, an open-source firmware stack based on the Yocto Project. This lets an organization build and configure its own BMC firmware using the Linux kernel toolchain, rather than relying on vendor releases.
OpenBMC is expected to provide a set of benefits that directly address the constraints of proprietary stacks:
- Latest stable and patched Linux kernel
- Internally-managed TLS certificates for secure, trusted communication across the isolated management network
- Fine-grained credentials management
- Faster response time for patching and critical updates
Because the codebase is open and community-driven, fixes for vulnerabilities like Pantsdown are patched quickly rather than waiting on vendor timelines.
We have previously worked on securing the boot process with a hardware root-of-trust. The BMC, however, has its own boot sequence that starts as soon as power is applied. Newer BMC chips, along with security co-processors, will allow us to validate cryptographic signatures on our BMC and OpenBMC firmware before our UEFI firmware even loads. Extending the secure boot chain to the very first powered device in our systems significantly reduces the risk of malicious implants that could take a server offline.
This vulnerability was resolved with a straightforward firmware update and coordinated action between our teams and Quanta. But securing the BMC will continue to be an area of focus as we push toward OpenBMC and a longer hardware root of trust. We are committed to reporting risks and mitigations transparently so that you can evaluate how seriously we take the security of our fleet and your data.
