Hitachi Energy Patches 7 Flaws in RTU500 SCADA Devices That Could Cause Repeated Reboots

A just-published U.S. government advisory reveals seven distinct vulnerabilities in Hitachi Energy’s RTU500 series remote terminal units—workhorses of the electrical grid—that can be triggered remotely to force devices into repeated reboots. The most dangerous of the batch, CVE-2023-2953, allows an unauthenticated attacker to crash the unit by sending a specially crafted request to the OpenLDAP library, earning a CVSS v4 score of 8.2. Patches are now available for nearly all affected firmware branches, but the window to apply them is narrow: these devices sit in critical infrastructure where even brief outages can cascade.

The Advisory at a Glance: What Hitachi and CISA Disclosed

On September 16, 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) published Industrial Control Systems Advisory ICSA-25-259-02, detailing seven vulnerabilities in Hitachi Energy’s RTU500 series. The flaws span several third-party software components embedded in the devices:

• OpenLDAP: a NULL pointer dereference (CVE-2023-2953) that requires no authentication and can cause an immediate DoS by rebooting the unit.
• libexpat: four XML parsing flaws (CVE-2024-45490, CVE-2024-45491, CVE-2024-45492, CVE-2024-28757) that can lead to heap corruption, integer overflow, or memory mismanagement when the device processes malicious XML—these require a low-privilege authenticated session.
• libxml2: a stack-based buffer overflow (CVE-2025-6021) in the web server component, also requiring authentication.
• IEC 61850 protocol: a crafted message can disconnect the device from the network (CVE-2025-39203), needing low-privilege access.

All seven vulnerabilities result in denial-of-service—the device reboots, dropping its monitoring and control functions. Hitachi has confirmed that affected firmware versions span the 12.7.x, 13.4.x, 13.5.x, 13.6.x, and 13.7.x branches. The exact mapping is complex; not every CVE applies to every branch. For example, CVE-2023-2953 afflicts 12.7.1–12.7.7, 13.5.1–13.5.3, and 13.6.1, while the libexpat issues primarily affect 13.7.1–13.7.6. (A full table of firmware targets is included in the mitigation section below.)

Why This Matters for Energy Grid Operators

If you operate an electrical utility, a power plant, or any industrial facility that relies on RTU500 series units for remote monitoring and control, this advisory demands your immediate attention. A successful DoS attack won’t steal data or enable remote code execution—at least not according to current disclosure—but it will knock your RTU offline. In a substation, a blinded RTU means lost visibility into breaker states, transformer loads, and protective relay status. Repeated reboots could disrupt automated protective schemes or force manual intervention, increasing operational risk.

For IT/OT security teams, the grading varies by deployment. Facilities with internet-exposed RTU management interfaces are at extreme risk from CVE-2023-2953, as it requires no credentials. Organizations that rigorously air-gap their control networks or use strict jump-host access still need to worry about the authenticated flaws, because a compromised engineer laptop or a malicious insider could send crafted XML or IEC 61850 messages. The libexpat and libxml2 bugs all require only low-level credentials (think: an operator account with access to the IEC 61850 client or the web server), which are not difficult to obtain in poorly managed OT environments.

The CVSS scores highlight the disparity: the OpenLDAP flaw scores 8.2 (v4), while the authenticated XML issues score between 6.9 and 7.1. But in an OT context, availability is paramount, and even a “low severity” DoS can be operationally catastrophic if it hits at the wrong time. Prioritize by impact on your grid topology, not by a single number.

How Open-Source Library Flaws Infiltrated the RTU500 Supply Chain

The RTU500 series has been deployed globally for more than a decade, forming the backbone of many utility automation systems. Like countless embedded devices, it relies on open-source libraries—OpenLDAP for directory services, libexpat and libxml2 for XML processing—that get integrated during development but often lag behind upstream security patches. This is a familiar pattern: in 2023 and 2024, multiple CVEs were published against these libraries, and Hitachi (along with other vendors) had to backport fixes into their firmware.

CVE-2023-2953, for example, was originally reported in OpenLDAP in May 2023. The libexpat flaws were disclosed throughout 2024. It has taken over a year for these patches to percolate into the RTU500 firmware. This delay is not unusual in ICS; vendors must test thoroughly to avoid bricking devices in the field. However, the lag means that the window of exposure can be long, and attackers know it. Although CISA reports no known active exploitation, the publication of the advisory will almost certainly trigger reverse engineering and scanning for vulnerable units.

Immediate Steps to Secure Your RTU500 Fleet

Hitachi has released firmware updates for most affected branches. Here is the concise upgrade map, assembled from the CISA advisory and Hitachi’s PSIRT note 8DBD000220:

For the 12.7.x branch, the 12.7.8 update is not yet available; the advisory advises using “general mitigation factors” until it is released. That means you must immediately strengthen network controls on those devices.

Critical immediate actions for all firms:

1. Isolate the RTU management interfaces. Ensure no RTU500 web server, IEC 61850, or CAM (Central Account Management) client is reachable from the internet or even the corporate IT network. Put them behind dedicated OT firewalls with strict allowlist rules.
2. Disable unused services. If you do not use CAM, disable the OpenLDAP client. If the web server and IEC 61850 client/server are not needed, turn them off. The advisory explicitly mentions that these components are attack vectors.
3. Enforce encrypted remote access. If remote maintenance is required, route all connections through a VPN with multi-factor authentication, and never allow direct IP reachability.
4. Roll out the firmware patches in a staged manner. Start with the RTUs in the most critical substations, test the update in a lab if possible, and keep rollback firmware on hand. Remember that upgrading RTU firmware often requires a maintenance window because the device will reboot during the process.
5. Rotate credentials and audit accounts. Since many of the CVEs need credentials, immediately change passwords for all accounts that can access RTU500 services. Use strong, unique passwords and, where supported, enable MFA. Remove any default or shared accounts.
6. Increase monitoring. Log all access attempts to RTU500 interfaces and set up alerts for repeated connection resets or unscheduled reboots. Anomalies in IEC 61850 MMS traffic or unexpected XML parsing errors could indicate exploitation attempts.

For organizations still on 13.4.x or other branches without a direct patch, apply the general mitigations: network isolation, minimal services, monitoring. Hitachi’s advisory notes that for some CVEs on certain branches, only “general mitigation factors” are available—meaning you must rely on defense-in-depth until a firmware fix is released.

What to Watch Next: The Open-Source Patching Lag in ICS

This advisory is unlikely to be the last for Hitachi Energy or for ICS devices that bundle open-source libraries. As security researchers continue to scrutinize the software supply chain, more buried vulnerabilities will surface. For utilities and industrial operators, the takeaway is clear: maintain a living inventory of every RTU and its firmware version, track vendor PSIRT portals, and establish a rapid-but-safe patch cycle. The energy sector’s operational technology is now a permanent target, and the lag between library disclosure and device patch is measured in months or years—but your response must be measured in days. Watch for Hitachi’s 12.7.8 release and any additional updates as the supply chain catches up. And if you haven’t already, map your network to confirm that no RTU500 ever touches the open internet.