CVE-2025-59375: Hitachi Energy REB500 Substation Protection DoS Flaws — Detection and Mitigation Guide

CISA published ICS advisory ICSA-26-279-05 covering two denial-of-service vulnerabilities in Hitachi Energy's REB500 busbar protection system — a device class that sits at the heart of electrical substation protection schemes worldwide. Versions REB500 8.3.3.1 and earlier are affected by CVE-2024-8176 (CWE-674, Uncontrolled Recursion) and CVE-2025-59375 (CWE-770, Allocation of Resources Without Limits or Throttling), both inherited from vulnerable open-source software components embedded in the product. Hitachi Energy has confirmed the issues and published recommended immediate actions; CISA has assigned a CVSS v3 score of 6.5 (medium severity).

A 6.5 might not trigger alarm in an IT patch queue. In an OT environment, the calculus is different. REB500 is busbar protection — the relay that clears busbar faults before they cascade into wider grid instability. A denial of service against this device doesn't just knock a service offline; it can blind or degrade a critical protection function in an energized substation. Defenders in the energy sector need to treat this advisory with disproportionate urgency relative to its raw score.

Technical Analysis

Affected Products and Versions

Root Cause

Both vulnerabilities trace to third-party open-source libraries bundled into the REB500 firmware — a recurring pattern in ICS advisories and one of the core reasons software bill of materials (SBOM) management matters in OT. The weakness classes tell the story:

• CVE-2024-8176 — Uncontrolled Recursion (CWE-674). A parsing component fails to bound recursion depth when processing crafted input. An attacker who can feed malicious structured data to the affected interface can drive the parser into unbounded recursion, exhausting the stack and crashing the process or the device.
• CVE-2025-59375 — Allocation of Resources Without Limits or Throttling (CWE-770). The component accepts input that triggers disproportionate memory or CPU allocation — processing oversized or deeply nested structures without an upper bound — until available resources are consumed and the device degrades or restarts.

In both cases the attack chain is short: network-reachable input → crafted payload → resource exhaustion → loss of the protection function or watchdog reboot. No authentication bypass or code execution has been reported — the impact is availability, which is precisely the property that matters most for protection relays.

Exploitation Requirements and Status

• Exploitation requires network reachability to the affected service/interface on the relay. This is why substation zone/conduit segmentation (IEC 62443) is the decisive control here.
• As of publication, there is no confirmed in-the-wild exploitation and neither CVE is listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The exposure is real but currently theoretical — which is exactly when you want to remediate, not after a proof of concept circulates.
• Because these flaws live in an open-source component, defenders should assume public technical detail (and eventually PoC) will emerge from the upstream library ecosystem even if no ICS-specific exploit exists today.

Detection & Response

A caveat from the field: you will not detect "CVE-2025-59375" with a signature. What you can detect are the two things an attacker must produce — crafted input delivered to the relay and the relay's resulting instability (watchdog reboots, service crashes, connection resets). Instrument both sides.

Sigma Rules

The first rule watches substation/ICS syslog (forwarded via CEF/Syslog to your SIEM) for crash and watchdog indicators consistent with resource-exhaustion DoS against a protection relay. The second targets the delivery vector — XML parser recursion flaws are reliably triggered by entity-expansion or deeply nested documents, so look for the tell-tale payload scaffolding hitting ICS management interfaces through your web/proxy telemetry.

---
title: ICS Protection Relay Crash or Watchdog Reboot Event
id: 3c8f2e61-7a94-4b1d-9e25-6f4a1c0d8b72
status: experimental
description: Detects watchdog resets, process crashes, and memory exhaustion indicators in syslog forwarded from substation protection relays such as Hitachi Energy REB500, consistent with resource-exhaustion DoS (CVE-2024-8176, CVE-2025-59375).
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-279-05
  - https://attack.mitre.org/techniques/T0814/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.impact
  - attack.t0814
logsource:
  product: linux
  service: syslog
detection:
  selection:
    Message|contains:
      - 'watchdog reset'
      - 'watchdog timeout'
      - 'out of memory'
      - 'OOM'
      - 'segmentation fault'
      - 'stack overflow'
      - 'recursion limit'
      - 'service restarted'
      - 'unexpected reboot'
falsepositives:
  - Firmware upgrades and scheduled relay maintenance windows
  - Known hardware faults under vendor investigation
level: high
---
title: Crafted XML Entity Payload Toward ICS Management Interface
id: 9b1d4a77-2e56-4f38-a0c1-5d8e3b6f9c40
status: experimental
description: Detects XML documents containing entity declarations (entity-expansion / recursive-parse scaffolding) in HTTP requests destined for ICS device management interfaces, a delivery pattern consistent with uncontrolled-recursion parser DoS (CVE-2024-8176).
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-279-05
  - https://attack.mitre.org/techniques/T1499/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.impact
  - attack.t1499.004
logsource:
  category: proxy
detection:
  selection:
    cs-method: 'POST'
    cs-uri|contains:
      - 'config'
      - 'upload'
      - 'import'
      - 'xml'
      - 'settings'
  payload:
    request-body|contains:
      - '<!ENTITY'
      - '<!DOCTYPE'
  condition: selection and payload
falsepositives:
  - Legitimate SCL/ICD/CID substation configuration file uploads by protection engineers — whitelist known engineering workstation source IPs and maintenance windows
level: medium

Tuning note: The second rule will fire on legitimate substation configuration language (SCL) file handling if you don't scope it. Pair it with an allowlist of engineering workstation IPs and approved maintenance windows before enabling alerting; leave it in hunting mode if you can't.

KQL — Microsoft Sentinel / Defender

This hunt assumes substation relay syslog and network device logs are ingested via CEF (CommonSecurityLog) or Syslog. It correlates two signals: a connection-rate anomaly against the relay followed by crash/reboot indicators — the observable fingerprint of a resource-exhaustion attempt.

let RelayDevices = dynamic(["REB500", "10.10.20.0/24"]); // replace with your relay hostnames/substation subnets
let Window = 10m;
// Stage 1: connection-rate anomaly toward relay interfaces
let Flood =
    CommonSecurityLog
    | where TimeGenerated > ago(24h)
    | where DestinationIP in (RelayDevices) or DeviceProduct has "REB500"
    | summarize ConnCount = count(), DistinctSources = dcount(SourceIP) by DestinationIP, bin(TimeGenerated, Window)
    | where ConnCount > 500; // baseline against normal SCADA polling rates first
// Stage 2: crash / watchdog indicators from the same relay
Syslog
| where TimeGenerated > ago(24h)
| where HostIP in (RelayDevices) or HostName has "REB500"
| where SyslogMessage has_any ("watchdog", "out of memory", "segmentation fault", "stack overflow", "reboot", "service restarted")
| join kind=inner (Flood) on $left.HostIP == $right.DestinationIP
| project FloodWindow = TimeGenerated1, ConnCount, DistinctSources, RelayIP = HostIP, SyslogMessage, TimeGenerated
| order by FloodWindow desc;

Baseline before you alert: SCADA masters and engineering tools poll relays on fixed cadences, so "high connection count" thresholds must be derived from your substation's normal traffic profile, not the default in the query. A threshold tuned to 2-3x your observed baseline per 10-minute window is a reasonable starting point.

Velociraptor VQL

Engineering workstations are the most likely pivot point an attacker would use to reach a relay. This artifact profiles outbound connections from Windows endpoints to OT protocol ports (IEC 61850 MMS/TCP 102, IEC 60870-5-104/TCP 2404, DNP3/TCP-UDP 20000, Modbus/TCP 502) and flags hosts with unusual connection fan-out — a precursor signature for payload delivery at scale.

-- Hunt for endpoints with anomalous connection volume to substation/ICS protocol ports
SELECT Pid,
       Name AS Process,
       Path AS ExePath,
       DestIP,
       DestPort,
       Status,
       count() AS ConnCount
FROM netstat()
WHERE DestPort in (102, 502, 2404, 20000)
  AND Status =~ 'ESTAB|SYN'
  AND NOT DestIP =~ '^(10\\.10\\.|192\\.168\\.50\\.)' -- exclude known SCADA master subnets
GROUP BY Pid, Name, Path, DestIP, DestPort, Status
HAVING ConnCount > 20
ORDER BY ConnCount DESC

Deploy this against your engineering workstation and jump-host collections. Any endpoint outside the authorized SCADA master set holding 20+ concurrent sessions to relay protocol ports is worth a DFIR look — legitimate protection engineering tools rarely fan out like that.

Verification and Hardening Script

The script below inventories reachable relays via SNMP sysDescr, flags firmware strings at or below the vulnerable 8.3.3.1 baseline, and audits host firewall rules on a Linux jump host for OT-port exposure. Adapt OIDs/community strings to your environment — and never run write operations against a protection relay outside an approved change window.

#!/usr/bin/env bash
# REB500 exposure audit — read-only verification against ICSA-26-279-05
# Usage: ./reb500_audit.sh <relay_ip_list.txt>

RELAY_LIST="${1:-relays.txt}"
SNMP_COMM="readonly_comm"          # replace with your read-only SNMP community
VULN_CEILING="8.3.3.1"

echo "[+] Auditing REB500 firmware versions against advisory ICSA-26-279-05"
while read -r RELAY; do
  DESCR=$(snmpget -v2c -c "$SNMP_COMM" -Oqv "$RELAY" SNMPv2-MIB::sysDescr.0 2>/dev/null)
  if [ -z "$DESCR" ]; then
    echo "[!] $RELAY : no SNMP response (verify reachability/community)"
    continue
  fi
  VER=$(echo "$DESCR" | grep -oE '8\.[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  if [ -z "$VER" ]; then
    echo "[?] $RELAY : version not parsed from sysDescr — manual check required: $DESCR"
    continue
  fi
  if [ "$(printf '%s\n%s\n' "$VER" "$VULN_CEILING" | sort -V | head -1)" = "$VER" ]; then
    echo "[VULNERABLE] $RELAY : firmware $VER <= $VULN_CEILING (CVE-2024-8176 / CVE-2025-59375)"
  else
    echo "[OK] $RELAY : firmware $VER"
  fi
done < "$RELAY_LIST"

echo "[+] Auditing jump-host firewall exposure on OT protocol ports"
for PORT in 102 502 2404 20000; do
  RULES=$(iptables -L INPUT -n | grep -E "dpt:$PORT" | grep -c ACCEPT || true)
  if [ "$RULES" -gt 0 ]; then
    echo "[REVIEW] TCP $PORT has $RULES ACCEPT rule(s) — confirm source-IP restriction to authorized SCADA masters only"
    iptables -L INPUT -n --line-numbers | grep "dpt:$PORT"
  fi
done

echo "[+] Done. Feed [VULNERABLE] and [REVIEW] findings into your change-management queue."

Remediation

1. Patch per the vendor advisory. Hitachi Energy has published recommended immediate actions alongside the advisory — upgrade REB500 installations to the fixed firmware release referenced in the Hitachi Energy security advisory (versions later than 8.3.3.1). Coordinate through Hitachi Energy Grid Automation support and schedule within an approved substation maintenance window; firmware changes on busbar protection require formal outage/change approval, not ad-hoc action.
2. Enforce zone-and-conduit segmentation (IEC 62443). Until patched, the compensating control is reachability. Verify that relay management and configuration interfaces are reachable only from explicitly authorized engineering workstations and SCADA masters, across firewalled conduits. No relay service should be routable from IT networks, vendor VPN concentrators, or jump-boxes with broad access.
3. Restrict and monitor file/payload delivery paths. If your operational workflow uploads SCL/ICD/CID configuration files to relays, confine that capability to a hardened engineering workstation, scan files before transfer, and alert on delivery attempts from any other source (see detection content above).
4. Add crash telemetry to your SIEM now. Forward relay syslog (watchdog, reboot, memory-fault events) via CEF/Syslog into Sentinel/your SIEM and enable the correlation logic above. DoS against protection systems is only detectable if the device health signal leaves the substation.
5. Track the upstream component. Because both CVEs originate in an open-source library, subscribe to the upstream project's security feed and Hitachi Energy's product security advisories — follow-on fixes in the same component are likely to require another firmware cycle.
6. Report and track. CISA encourages organizations to report suspected exploitation of these vulnerabilities and to follow its ICS recommended practices. No KEV deadline applies today, but energy-sector operators subject to NERC CIP should document remediation through their CIP-010 change management and CIP-007 patch management processes.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub