Inside the Neocloud (Part 2): When the Management Network Isn’t Isolated

Some GPU cloud and neocloud providers offer bare-metal servers, giving customers full administrative control over the machines they rent. But every physical server also has a separate management layer that allows providers to remotely control hardware, manage firmware, and operate their infrastructure.

This management layer is supposed to remain under the provider’s control, even when customers have full access to the operating system.

During our security research, we identified two different misconfigurations in rented GPU servers. In one environment, a tenant could reach the provider’s internal management network. In another, a tenant could gain administrative control of the server’s management controller.

Neither required a sophisticated exploit.

What Is a BMC, and Why Does It Matter?

A Baseboard Management Controller (BMC) is a small, independent computer built into a physical server. Examples include Dell iDRAC and HPE iLO. Unlike the server’s operating system, the BMC operates independently and remains available even when the server is powered off, as long as standby power is present.

BMCs allow infrastructure operators to remotely power servers on and off, update firmware, access consoles, and reinstall operating systems. Because of these capabilities, administrative control of a BMC provides a level of access comparable to physical access to the server.

BMCs typically connect to a dedicated out-of-band (OOB) management network, alongside switches and other infrastructure management interfaces. This network is intended to be accessible only to authorized provider systems.

The challenge with bare-metal GPU clouds is that customers already have root access to the physical host. Providers must ensure that controlling the operating system does not also grant access to its BMC or the broader management network.

How Servers Communicate With Their BMCs

Two common technologies are used to manage BMCs: IPMI (Intelligent Platform Management Interface) and Redfish.

IPMI is an older management protocol used for hardware monitoring, power control, and user management. Redfish provides similar capabilities through a modern API.

BMCs can be accessed over dedicated management networks, but some also expose local management interfaces directly to the host operating system.

These local interfaces were originally designed for trusted administrators. Depending on the BMC’s configuration, they may allow certain operations without requiring separate BMC credentials.

This creates a security challenge when the person controlling the operating system is a customer rather than the infrastructure provider.

Finding #1: A Tenant Could Reach the Provider’s Management Network

While renting bare-metal GPU servers as regular customers, we investigated whether the hosts could communicate with their management controllers.

In one environment, we discovered that the host exposed information about its BMC, including its private management address.

When we attempted to reach that address from the rented server, the BMC responded and exposed information through its management API.

But the issue extended beyond a single server. From the same rented host, we could reach private management networks containing BMCs across the provider’s fleet and other network infrastructure.

Why Was This Possible?

The tenant and management networks shared routing infrastructure, and a missing Access Control List (ACL) allowed customer traffic to reach the management network.

The addresses were private, but the networks weren’t properly isolated.

Private IP addresses do not provide security by themselves. Without proper network segmentation, internal management interfaces can become accessible to customers.

The exposed network also contained IPMI services, which can introduce additional risks when weak, default, or reused credentials are present.

IPMI 2.0 has a known authentication vulnerability, CVE-2013-4786, that can expose password-derived information and enable offline password guessing.

Reaching a BMC does not automatically provide administrative control, but it significantly increases the attack surface.

In this case, a single missing network rule exposed management interfaces that should never have been reachable from a customer server.

Finding #2: A Tenant Could Become the BMC Administrator

In another GPU cloud environment, network segmentation was working correctly. The rented host couldn’t directly reach the provider’s management network.

However, we discovered a different path through the server’s local management interface.

This interface allowed the host operating system to communicate directly with the BMC, without going through the management network.

During our assessment, we found that the BMC permitted administrative user management through this local interface.

We were able to create a new BMC administrator account without knowing any existing BMC credentials.

We then verified that the new account could authenticate to the BMC and access privileged management functions, including power management, virtual media, user administration, and firmware management.

The tenant had legitimate root access to the rented operating system, but that access should not have extended to administrative control of the provider’s management controller.

Why Is This Dangerous?

Unlike an operating system account, a BMC administrator account can survive operating system reinstalls unless it is explicitly removed.

This creates several potential risks:

• Persistent access: Unauthorized BMC accounts may remain active after a server is reinstalled or reassigned.

• Hardware control: An attacker could gain access to privileged hardware management functions.

• Future tenants: A new customer could inherit a server whose BMC was modified by a previous tenant.

• Management network exposure: A compromised BMC may have connectivity to other infrastructure management devices.

During our research, we also confirmed that the BMC could discover neighboring devices on its management network.

We did not compromise those devices or demonstrate unrestricted access to the broader management network from the BMC.

However, the confirmed finding was already critical: a regular bare-metal tenant could create an administrator account on infrastructure controlled by the provider.

What Should Providers Check?

These findings highlight the importance of protecting both network access to management infrastructure and local communication between hosts and BMCs.

1. Isolate management networks: Ensure tenant environments cannot reach BMCs, switches, or other management interfaces. Validate segmentation across all relevant network paths.

2. Restrict host-to-BMC access: Review local management interfaces and prevent tenant-controlled operating systems from performing privileged BMC operations.

3. Protect BMC credentials: Use strong, unique credentials, disable unnecessary management services, and avoid relying on factory defaults.

4. Reset BMC access between tenants: Remove unauthorized accounts and configuration changes before reassigning physical servers.

5. Validate isolation from the tenant’s perspective: Test what customers can actually reach and control, rather than relying only on infrastructure configuration reviews.

The Bigger Picture

Both findings exposed the same underlying problem from different directions.

In the first environment, a missing network rule allowed tenants to reach the provider’s management infrastructure. In the second, the BMC trusted the tenant-controlled operating system enough to allow the creation of new administrators.

Neither required exploiting a previously unknown vulnerability. These were configuration and trust-boundary failures in infrastructure designed to operate below the customer’s environment.

This research relates to #4: Insecure Out-of-Band Management Plane in the OWASP Top 10 Neocloud & AI Data Center Security Risks.

Giving customers root access to a server should never mean giving them control over the infrastructure that manages it.

Inside the Neocloud is a three-part research series by Lava exploring security risks uncovered during real-world assessments of GPU clouds and AI infrastructure.

Part 1: When the Container Is the Only Wall⁠

Part 3: When InfiniBand Isolation Fails