Attacking UPS Network Cards to Take Down Data Centers

Executive Summary

• Team82 uncovered two critical vulnerabilities in Vertiv’s Liebert IS-UNITY-DP network cards, both assessed a CVSSv3 score of 9.8.

• These cards are a network interface for Vertiv’s line of uninterruptible power supply (UPS) devices

• UPS are heavily used in data centers to maintain operations in the event of a power outage; they also protect systems from power spikes and drops, and enable safe shutdowns

• CVE-2025-46412 is an authentication bypass vulnerability that allows an attacker to access the devices via a web-based interface

• CVE-2025-41426 is a stack-based buffer overflow vulnerability that enables remote code execution on affected devices. 

• Vertiv has provided updates that address both flaws disclosed by Team82. 

• The vendor recommends users take the following actions: Update Liebert RDU101 to v1.9.1.2_0000001, and update IS-UNITY to v8.4.3.1_00160

Introduction

Team82 has uncovered two serious vulnerabilities in Vertiv’s uninterruptible power supply (UPS) network cards that enable authentication bypass to the control interface of the UPS, denial of service, and potentially code execution.

UPS devices come in all sizes, from units as small as a laptop to as big as a six-door closet. They serve the same purpose: keeping critical equipment running in the event of a power outage. During an outage, a UPS switches to its internal battery, preventing sudden shutdowns. Data centers, for example, rely on them to keep servers, routers, and control systems stable and protected from power spikes or drops, keeping devices online or shutting them down safely.

Successful exploits of CVE-2025-46412 and CVE-2025-41426 could allow an attacker to not only access vulnerable devices, but also execute arbitrary code that could cause damaging disruptions to organizations reliant on these devices for uptime and service reliability. 

Choosing a Research Target: Vertiv Liebert UPS

Many UPS units don’t include a network interface out of the box. If network access is required, users usually need to separately buy a communication card. Adding this card provides several useful benefits, including UPS management over Ethernet connections instead of a local USB connection, and monitoring and alarm capabilities via common network protocols such as SNMP, Modbus, or BACnet. This allows integration with other systems. Some UPS vendors integrate with platforms such as VMware vSphere, enabling the UPS to communicate directly with the virtualization layer and orchestrate shutdowns of virtual machines when they power off.

UPS network card security is crucial because of the impact it can have over connected devices such as servers, routers and firewalls, and were the perfect high-impact target for this research project. 

For this research, we chose Vertiv, a top-tier global UPS vendor. Formerly Emerson Network Power, Vertiv’s Liebert UPS systems serve several important verticals, including data centers and other critical infrastructure markets. We were able to access Vertiv firmware online as it's publicly available from the vendor.

Vertiv sells several different models of communication cards that are compliant with its UPS units, the most popular is Liebert IS-UNITY-DP and Liebert RDU101, which we researched.

Vertiv Communication Cards

Usually when we start reviewing firmware, the first thing we want to know is the operating system and the architecture. Knowing these two things gives us a rough idea of how complex it will be to understand and execute the cards' components.

Vertiv manufactures several product lines, while the most popular being the Vertiv RDU101 (Linux ARM 32 bit) and Vertiv UNITY-DP (Linux PowerPC). The main applications within the card are the same we used for the research. Vertiv UNITY-DP was much easier for us to obtain, however PowerPC architecture is a platform that is less convenient for research, so we decided to purchase the UNITY-DP to be able to validate our findings but perform the vulnerability research on RDU101.

We invest considerable effort on setup for dynamic research. Our interest is to be able to debug the running applications, thus speeding up vulnerability discovery and validation. The network card runs several services, and since the operating system is Linux and the architecture is ARM, getting the services running, with some limitations because of missing peripherals, is relatively straightforward. 

We chose RaspberryPi as our run environment and the Vertiv card applications will run on its OS and kernel.  The firmware is an archive with a device tree, kernel and the root file system. We are looking for vulnerabilities only in user-level programs, so for our research we are interested only in the content of the root file system. These steps prepare the environment in order for Vertiv’s application to run:

1. Extract the firmware within the RaspberryPi into directory FW_DIR.

2. Mount the /proc and /dev directories into FW_DIR/proc and FW_DIR/ dev.

3. Perform chroot into the environment and execute /bin/sh.

# scp firmware_archive pi@10.10.10.7:/home/pi
# ssh pi@10.10.10.7
--------------
$ binwalk -e /home/pi/firmware_archive
$ mv BINWALK_ROOTFS_DIR FW_DIR
$ sudo mount -t proc /proc ./FW_DIR/proc
$ sudo mount --bind /dev ./FW_DIR/dev
$ sudo chroot ./FW_DIR /bin/sh
--------------
# chrooted FS

When the binaries are executed, the libraries will be loaded relative to the chrooted file system and not the original RaspberryPi’s.

The Vertiv RDU101/Unity cards expose numerous services, from management interfaces to monitoring applications. From a research perspective, we’re interested in the ones that present the largest attack surface, such as the web interface, which is available by default. 

The web interface provides the configuration features for the card and the UPS unit, and is usually not opted-out by users. After choosing this attack vector, the next step was understanding how the web server is bootstrapped so we could recreate it in our RaspberryPi environment.

Attack Vector: Web Interface.

The Vertiv web interface provides tools for configuring the card and the UPS unit:

The complexity of bootstrapping the web interface in a non‑native environment changes from target to target. Sometimes it’s as simple as starting the httpd daemon with an existing configuration. Other times, the web service depends on a whole chain of supporting applications such as configuration or database daemons, which complicates bringing up the service in a useful way.

Vertiv’s setup was somewhere in the middle. The web server is Apache’s httpd using the mod_fcgi module, a common configuration. But the entire Vertiv ecosystem, including the web interface, relies heavily on PLDServer. PLDServer is a proprietary application that is responsible for most of the internal operations of the card and communicating with other services via proprietary interprocess communication (IPC).

Executing the PLDServer required heavy binary patching therefore we decided to not invest in it.  Running only the web layer without the PLDServer gave us some of the initial HTTP request handling flow, but it stops short: the response comes back empty. Although we couldn’t actually browse the UI the way we would on the real device, the authentication procedure functions and we decided to focus on it.

We started the research by looking into the pldproxyweb binary, the component to which mod_fcgi forwards dynamic requests. When approaching a web service like this, researchers typically start with a few core questions:

• Which routes (endpoints) don’t require authentication?

  • Are any of these unauthenticated resources vulnerable?

  • And for the endpoints that should require authentication, are they actually protected?

• How is authentication enforced internally?

  • And is there any weakness in that logic that could potentially be bypassed?

URI Confusion Vulnerability

At first, it didn’t look like this was going to be an easy win: the code lacked a “forgot password” recovery flow, memory handling looked solid, uploaded file names were properly constrained, and at a glance the authentication checks didn’t seem like they would hand us the CVEs we were hoping for. 

However, one thing did catch our attention. The way the request type was determined relied on checking whether a specific string appeared in the query without constraints on its location. This kind of approach can open the door to URI endpoint confusion, even though the rest of the code looked correct, this stood out as something worth looking into.

To explain the vulnerability we used sample code instead of the real code on the firmware due to its sensitivity. Consider the following example, a server with two endpoints:

1. /login: endpoint that does not require authentication

2. /reset_admin_password: endpoint that does requires authentication

To call the endpoints, the client will issue an HTTP request:

GET /login?user=admin&pass=admin

GET /reset_admin_password?new_pass=admin1&sessID=SESS_FOR_LOGGED_USER

The code within the sample web server is the following:

if “login” in query or perform_authorisation() == OK {
//authenticated or do not need to be authenticated yet.
	if “login” in query:
		perform_login()
	elif “reset_admin_password” in query:
		reset_admin_password()
}
else {
//If this code is reached the authorization verification failed.
	log("Authentication failed")

The code above checks whether the login string is part of the HTTP query, and if not, the server will verify authorization. If it does, the code will enter the if section without checking for authorization (as desired).

At first glance there is no problem. But what will happen if the code will be slightly changed:

if “login” in query or perform_authorisation() == OK {
//authenticated or do not need to be authenticated yet.
if “reset_admin_password” in query:
		prform_reset_admin_password()
	elif “login” in query:
		perform_login()
}
else {
//If this code is reached the authorization verification failed.
	log("Authentication failed")
}

The only change from the previous code snippet is the order of the inner if/else condition. However, what happens if the following route is requested (without authorization token)?

GET /login/reset_admin_password

Within the first code sample, the login procedure will be initiated. However within the second code sample, the admin password will be reset without authorization verification. 

Now, just because the request type is determined by the mere presence of a specific string, rather than their presence in a specific location, there’s a chance, depending on how the developer ordered the checks in the code, that certain sensitive functions could slip through without proper validation.

It looks like, from static binary analysis, that this logic flaw exists in web server implementation on both Vertiv RDU101 and UNITY cards.That is, we can manipulate the order of execution functionality by placing the keywords in specific locations within the URL. This URL confusion vulnerability made it possible to bypass authentication for several high-impact operations, including configuration uploads and firmware upgrades.

It almost looked too easy. Was it really working? Our limited setup seemed promising, but we couldn’t be completely sure until we checked the vulnerability on  the actual device.

Exploiting Vertiv Liebert IS-UNITY-DP

The network card is not a standalone device; in a real-world configuration, the card is plugged into an edge connector chassis within the UPS unit. The budget for this project didn’t allow us to buy an UPS only to be able to power a network card (without mentioning that this thing could be the size of a family closet), so we needed to find another way to turn it on. 

After a brief moment of mild panic and thinking we might’ve ordered a device we couldn’t actually turn on, we realized that it was all the matter of providing the needed voltage via the card's power terminals. 

It wasn’t that simple. Since we wanted to power the board through its (seemingly proprietary) connector, we needed to know a few things:

• the input voltage

• the maximum wattage the board could handle

• which pins on the edge-connector are actually the input and the ground.

For that information, we normally rely on the board’s specifications datasheet, but one was not available. 

From the Liebert RDU101 product datasheet (not a board specifications datasheet),  the operating voltages are between 7- and 12-volt DC and maximum power consumption is 3.6 watts. 

We could not find this information for the Liebert IS-UNITY-DP we obtained, but assumed they are the same.

Now with the knowledge of desired voltage, we needed to find the board’s pinout for the power terminals. Unlike other UPS network cards that are designed to work across multiple vendors—and therefore have publicly available documentation—the Vertiv Liebert cards are meant only for Vertiv UPS units. That means no public board datasheet, no pinout.

Without documentation, we had to find the power pins with pinout analysis.

Starting with the ground; with the multimeter in continuity mode, we placed one probe on the USB shield and used the other to go over all 10 pins on the connector (5 on each side) until we got a beep. Once we found the GND (ground terminal) pin, we made life easier for ourselves by looking for an additional GND point that didn’t require any soldering, just put one probe on the known GND and touch the other to nearby pins or pads that are easy to clip onto.

The vin (supplied voltage terminal), as well as ground, have to be placed within the pins on the edge connector. When zoomed in, we saw that one of the connector pins is shorted to a fuse. Fuses are a common way to protect the whole board from current spikes, hinting that this pin carries the circuit current, i.e., is a voltage input; it’s an educated guess without the datasheet or PCB labels.

Next thing to do was to solder the vin pin to a jumper wire and to plug another wire to the GND pin:

We also can plug in the Ethernet cable:

Now we’re finally ready to hit the power button; we used an external DC power supply in order to monitor the voltage and limit the current. 

From the product brochure, we know the card’s maximum power consumption is 3.6 watts and the operating voltage is between 7-12 volts. We set the voltage supply to 10V (although anything in the 7–12 V range should be fine) and calculated the amperage limit:

Electronic boards are powered by the flowing current that is generated by voltage. The basic power formula for electronic systems is Power = Voltage x (I)Current. We determined the voltage to be 10 volts and we know that the maximum power that the board can operate upon is 3.6 watts.

So to find the amperage (current) limit, we need to put the values into the formula:

3.6 ≥ 10 ×A  ➜  A ≤ 3.6 ÷ 10  ➜  A ≤ 0.36

Therefore, the maximum limit for the current is 0.36.:

This did the trick as the Ethernet cable started to blink green.

After getting its IP address via ARP packets, we connected to the web interface via the browser.

CVE-2025-46412

Our attempt to log in using the known default password failed, which made sense considering it was a second-hand unit. Rather than reset the card to factory settings, we decided to attempt to access the card using our vulnerability. 

Vertiv Liebert cards support importing and exporting their configuration, and stored in the configuration are the username and password settings (the password can be only imported, not exported).

Since the vulnerability allows for a configuration file to be uploaded to the device, we are able to bypass authorization verification. If we can upload a configuration file with modified passwords to the device without authorization checks, and then log in to the web interface, that’s all the confirmation we need that the vulnerability exists.

Since we couldn’t access the UI yet, we used Burp to manually send the HTTP request. From reviewing the pldproxyweb binary, we knew the general structure of the expected request’s body and we know how it normally handles authentication through a session cookie. Because we have no session cookie, we simply omit the cookie header.

For sanity’s sake, we sent the request without using the vulnerability; expecting to get a 401 response (because of the omitted cookie header). We prepared a configuration file that would set a new password for the user and sent it to the card. Below, you can see the 401 response.

We then took advantage of the vulnerability to send the request (the route is omitted due to its sensitivity), which worked and was confirmed by the “upload successful” response:

This allowed us to log in with the newly configured password:

What does it mean? We have the ability to login into any publicly exposed Vertiv Liebert IS-UNITY-DP network card’s configuration interface that manages a single or multiple UPS units.

Aside from actions like preventing others from logging in to the web interface, an attacker can do real damage by requesting an “output OFF” in a managed UPS configuration, which in “UPS language" means shut down any powered-by-UPS device. In the case of a data center, an entire facility could be impacted by this one vulnerability. 

While we were able to shut off connected devices and change configurations, we still did not have remote code execution capabilities. 

CVE-2025-41426

While performing the binary analysis we found use of insecure function to perform copy from the buffer controlled by the user.

There are three strings that are copied into a buffer found on stack; HTTP_Method, URI_Request and another value sessACT. sessACT is an internal variable used for session integrity checks within the web server.

Since length of URI and sessACT is checked prior to entering this code we used REQUEST_METHOD to overflow the stack:

As a bonus, sessACT was taken from the HTTP request body and supports non-ASCII characters (in contrast to URI) which is very convenient when building a return-oriented programming (ROP) chain.

*Note: this vulnerability requires authentication (which can be bypassed with the first issue). 

Summary 

Through this research, we uncovered two vulnerabilities with a CVSS score of 9.8. What makes them especially concerning is the context: in large data centers, virtually all computing equipment relies on UPS devices to stay online during power issues. Any weakness in those UPS communication modules can directly affect the machines they protect.

Both vulnerabilities were disclosed to Vertiv and reproduced on the latest firmware versions of the Liebert IS-UNITY and Liebert RDU101 communication cards. Vertiv has provided updates that address both flaws disclosed by Team82. The vendor recommends users take the following actions: Update Liebert RDU101 to v1.9.1.2_0000001, and update IS-UNITY to v8.4.3.1_00160

Acknowledgement

We want to thank Vertiv for a smooth, cooperative disclosure process, and for addressing the issues quickly in an effort to protect its customers.