CISA has published ICSA-26-258-05 covering fourteen vulnerabilities in Siemens Reyrolle 7SR5 protection relays, all firmware versions before V2.70. Nine of the CVEs are 2026 disclosures (CVE-2026-62645 through CVE-2026-62654, excluding 62651), and the worst of the bunch carries a CVSS v3 base score of 9.8. The vulnerability classes listed are the ones that keep OT defenders up at night: missing authentication for critical function, integer overflow, improper input validation, use of out-of-range pointer offset, insufficient entropy, and improper neutralization of delimiters.
For those who don't live in the electric utility world: Reyrolle 7SR5 devices are numerical protection relays. They sit in substations and industrial facilities and make real-time decisions about tripping breakers when they detect faults on feeders, motors, and transformers. A compromised protection relay isn't a data-loss event — it's a physical consequence event. An attacker who can manipulate relay settings, issue unauthorized control commands, or crash the device can cause outages, equipment damage, or worse. We've watched adversaries target exactly this class of equipment in real-world grid attacks, so when an advisory drops with a 9.8 and 'missing authentication for critical function' in the CWE list, it goes straight to the top of the OT patch queue.
Siemens has released firmware V2.70 to remediate all fourteen issues. That update is the fix. Everything else in this post is about what you do before, during, and after you can get a maintenance window to deploy it.
Technical Analysis
Affected Products and Versions
- Product: Siemens Reyrolle 7SR5 protection relays (all 7SR5 variants)
- Affected firmware: All versions prior to V2.70
- Fixed version: V2.70 and later
- Advisory: CISA ICSA-26-258-05 (with CSAF machine-readable advisory available)
CVE Breakdown
The advisory bundles fourteen CVEs:
- 2026 disclosures: CVE-2026-62645, CVE-2026-62646, CVE-2026-62647, CVE-2026-62648, CVE-2026-62649, CVE-2026-62650, CVE-2026-62652, CVE-2026-62653, CVE-2026-62654
- Earlier disclosures carried in the same remediation: CVE-2024-42384, CVE-2024-42385, CVE-2024-42386, CVE-2024-42391, CVE-2024-42392
The presence of the older 2024 CVEs in this advisory is itself a lesson: Siemens appears to have consolidated fixes — including previously disclosed issues — into the V2.70 train. If your relays are still on pre-2024 firmware, you've been carrying exploitable vulnerabilities for over a year, and the 2026 additions make that exposure materially worse. The 2026 CVEs are the focus here.
Vulnerability Classes and Why They're Dangerous on a Relay
Working from the CWE categories in the advisory, here's what defenders should understand about the attack surface:
- Missing Authentication for Critical Function (9.8-class issue): A network-reachable function on the device — configuration, control, or a diagnostic/service interface — does not require authentication. On a protection relay, this is the nightmare scenario: any host that can route to the device can potentially invoke privileged functions. Exploitation requires network adjacency to the relay's Ethernet interface, nothing more. This is precisely why OT network segmentation is a compensating control of first resort.
- Integer Overflow or Wraparound / Out-of-range Pointer Offset: Classic memory corruption primitives, almost certainly reachable via malformed protocol traffic or crafted input to a parsing function. On embedded RTOS-based devices, successful exploitation typically yields remote code execution or a device crash/reset. Even the crash case is serious on a protection relay — a relay that reboots or hangs during a fault condition fails to protect.
- Improper Input Validation / Improper Neutralization of Delimiters: Suggests injection-style flaws in a management interface (web UI or configuration parser) — attacker-controlled input breaking out of expected fields into command or configuration contexts.
- Insufficient Entropy: Weak randomness in session tokens, keys, or authentication challenges, enabling session prediction or cryptographic downgrade attacks against the management plane.
Exploitation requirements: Network access to the relay. No user interaction. The 9.8 score reflects network vector, low complexity, no privileges, no user interaction, with high impact across confidentiality, integrity, and availability.
Exploitation Status
As of this writing, there is no confirmed in-the-wild exploitation of these CVEs, no public proof-of-concept code we are aware of, and these identifiers have not been added to the CISA Known Exploited Vulnerabilities catalog. That is the good news. The bad news is the pattern: ICS advisories with missing-authentication CVEs at 9.8 historically attract researcher attention quickly, and scanning for exposed protection relays is trivial for anyone with an internet-wide scan dataset. Treat 'not yet exploited' as a countdown timer, not a comfort blanket.
Detection & Response
Detection for embedded protection relays is different from endpoint detection. You will not get EDR telemetry from a 7SR5. Your visibility comes from network monitoring at the OT DMZ and substation level, from the engineering workstations that legitimately talk to these relays, and from relay/syslog forwarding where configured. The strategy: baseline which hosts should ever communicate with your relay VLANs, and alarm on everything else.
Sigma Rules
The following rules assume you are ingesting Zeek/firewall/network sensor data from OT network taps. Tune the destination networks and authorized engineering workstation lists to your environment — in OT, an allowlist-based rule is more accurate, not less, because legitimate traffic patterns are static.
---
title: Unauthorized Host Communicating with Protection Relay Management Interfaces
id: 4f8c2b91-7d3e-4a5f-9c1b-2e6d8a0f3b47
status: experimental
description: Detects network connections from non-engineering hosts to web/management services on protection relay segments. Reyrolle 7SR5 devices before V2.70 expose critical functions without authentication (CVE-2026-62645 through CVE-2026-62654), so any unexpected host reaching relay management ports is a high-fidelity alert.
references:
- https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-05
- https://attack.mitre.org/techniques/T0846/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.lateral_movement
- attack.t0846
logsource:
category: network_connection
detection:
selection_dst_net:
DestinationIp|cidr:
- '10.20.0.0/16' # TODO: replace with your relay/protection VLAN CIDRs
selection_ports:
DestinationPort:
- 80
- 443
- 8080
- 8443
filter_authorized_src:
SourceIp|cidr:
- '10.30.10.0/24' # TODO: replace with authorized engineering workstation subnet
condition: selection_dst_net and selection_ports and not filter_authorized_src
falsepositives:
- Newly commissioned engineering laptops not yet added to allowlist
- Authorized vulnerability scanning from OT security tooling
level: high
---
title: Unexpected Host Initiating ICS Protocol Traffic to Protection Relays
id: 8b1e6a34-2c9f-4d7b-a5e3-6f0c4d9b1e82
status: experimental
description: Detects DNP3, Modbus, or IEC 61850 MMS protocol connections to protection relay networks originating outside the approved control system and engineering zones. Malformed protocol input is the likely vector for the integer overflow and input validation flaws in the Reyrolle 7SR5 advisory.
references:
- https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-05
- https://attack.mitre.org/techniques/T0855/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.lateral_movement
- attack.t0855
logsource:
category: network_connection
detection:
selection_dst_net:
DestinationIp|cidr:
- '10.20.0.0/16' # TODO: replace with your relay/protection VLAN CIDRs
selection_ics_ports:
DestinationPort:
- 502 # Modbus
- 102 # IEC 61850 MMS / ISO-TSAP
- 20000 # DNP3
- 2404 # IEC 60870-5-104
filter_authorized_src:
SourceIp|cidr:
- '10.30.10.0/24' # Engineering workstations
- '10.30.20.0/24' # SCADA/RTU gateway zone
condition: selection_dst_net and selection_ics_ports and not filter_authorized_src
falsepositives:
- Legacy RTU or gateway devices with undocumented static IPs
- Maintenance vendor remote access sessions
level: critical
---
title: Engineering Workstation Process Spawning Shell After Relay Communication
id: c6a9d3f2-5e1b-4b8c-9d7a-3f2e8b6c0d15
status: experimental
description: Detects relay configuration or vendor engineering tools spawning command shells or script interpreters on engineering workstations. Post-exploitation activity following compromise of OT software or via a compromised relay management path frequently follows this pattern.
references:
- https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-05
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/15
tags:
- attack.execution
- attack.t1059.003
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\reydisp.exe' # Siemens Reydisp configuration tool
- '\digsi.exe' # Siemens DIGSI engineering tool (if present)
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
condition: selection_parent and selection_child
falsepositives:
- Vendor tool updaters invoking scripts during installation — restrict to interactive use windows
level: high
KQL — Microsoft Sentinel (via CEF/Syslog Ingestion from OT Firewalls)
This query hunts for unauthorized sources communicating with relay subnets over management and ICS protocol ports. It assumes your OT firewall or network sensor logs are flowing into Sentinel as CommonSecurityLog. Replace the CIDRs and authorized source list with your actual zones.
let RelaySubnets = dynamic(["10.20.0.0/16"]);
let AuthorizedSources = dynamic(["10.30.10.0/24", "10.30.20.0/24"]);
let ICSPorts = dynamic([80, 443, 502, 102, 20000, 2404, 8080]);
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where ipv4_is_in_range(DestinationIP, "10.20.0.0/16")
| where DestinationPort in (ICSPorts)
| where not(ipv4_is_in_range(SourceIP, "10.30.10.0/24"))
and not(ipv4_is_in_range(SourceIP, "10.30.20.0/24"))
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
Ports = make_set(DestinationPort), DestRelays = make_set(DestinationIP)
by SourceIP, DeviceAction, DeviceVendor
| extend RiskNote = iff(DeviceAction =~ "deny", "Blocked by firewall - validate segmentation policy", "PERMITTED - investigate immediately")
| order by ConnectionCount desc;
A 'PERMITTED' result from a host outside your engineering zone is a page-the-on-call event in an OT environment. A 'deny' result tells you something is trying — which is worth a threat hunt to find out what and why.
Velociraptor VQL — Engineering Workstation Hunt
Engineering workstations are the pivot point between corporate IT and your relays. This artifact looks for suspicious network connections to ICS protocol ports from unexpected processes on Windows engineering workstations.
-- Hunt for non-standard processes holding connections to ICS/management ports
-- Run against engineering workstation group via Velociraptor hunt
LET ics_ports <= (502, 102, 20000, 2404, 8080, 443)
LET approved_procs <= ("reydisp", "digsi", "svchost", "iexplore", "msedge", "chrome")
SELECT Pid, Name, Path, RemoteAddress, RemotePort, Status,
timestamp(epoch=now()) AS CollectionTime
FROM netstat()
WHERE RemotePort IN ics_ports
AND Status =~ "ESTAB"
AND NOT Name =~ "(reydisp|digsi|svchost|msedge|chrome|firefox)"
AND NOT RemoteAddress =~ "^(127\.|0\.0\.0\.0)"
Any process outside the approved engineering-tool set holding an established session to a relay is worth isolating the host over. In substations, legitimate communication patterns are boring — boring is your friend.
Verification & Hardening Script
The following Bash script helps OT security teams (a) inventory exposed Reyrolle-style management services on a relay segment and (b) confirm that segmentation rules are blocking unauthorized access. Run from a dedicated OT security sensor or authorized scanning host during an approved window — active scanning of live substation equipment should always be coordinated with operations.
#!/bin/bash
# Reyrolle 7SR5 exposure & segmentation verification (ICSA-26-258-05)
# Run ONLY from an authorized OT security host during an approved maintenance window.
RELAY_NET="10.20.0.0/24" # TODO: relay/protection VLAN
MGMT_PORTS="80,443,8080,8443"
ICS_PORTS="502,102,20000,2404"
OUTDIR="/var/log/ot-audit-$(date +%Y%m%d)"
mkdir -p "$OUTDIR"
echo "[*] Discovering live hosts on relay segment (ARP/passive-first)..."
sudo arp-scan --localnet --interface=eth0 > "$OUTDIR/relay-arp-inventory.txt" 2>/dev/null
echo "[*] Checking for exposed management interfaces (safe, no intrusive scripts)..."
sudo nmap -sS -Pn -p "$MGMT_PORTS" --open -T2 "$RELAY_NET" \
-oN "$OUTDIR/relay-mgmt-exposure.txt"
echo "[*] Enumerating ICS protocol listeners..."
sudo nmap -sS -Pn -p "$ICS_PORTS" --open -T2 "$RELAY_NET" \
-oN "$OUTDIR/relay-ics-listeners.txt"
echo "[*] Extracting open web interfaces for firmware verification queue..."
grep -h -B4 "80/tcp open\|443/tcp open" "$OUTDIR/relay-mgmt-exposure.txt" \
| grep "Nmap scan report" | awk '{print $NF}' > "$OUTDIR/relay-firmware-check-queue.txt"
echo "[*] Devices requiring V2.70 firmware verification:"
cat "$OUTDIR/relay-firmware-check-queue.txt"
echo ""
echo "[NEXT STEPS]"
echo " 1. For each IP above, log in via authorized engineering workstation and"
echo " record firmware version from device identification / Reydisp tool."
echo " 2. Any device below V2.70 -> schedule firmware update per Siemens advisory."
echo " 3. Cross-reference management-accessible IPs against firewall allowlists."
echo " 4. Confirm NO relay segment is reachable from corporate IT or internet paths."
Remediation
- Update firmware to V2.70 or later. This is the only complete fix — Siemens has stated that updating resolves all fourteen CVEs (CVE-2026-62645 through CVE-2026-62654 and the five carried 2024 CVEs). Obtain the firmware through Siemens' official support channels and validate integrity before deployment. Coordinate updates through your established OT change-management and outage-planning process.
- Review the official advisories: CISA ICSA-26-258-05 (https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-05) and the corresponding Siemens ProductCERT advisory, including the CSAF machine-readable version, which your vulnerability management platform can ingest directly.
- Enforce network segmentation as a compensating control until patched. The missing-authentication weakness means the only thing standing between an attacker and a critical function on an unpatched relay is your network architecture. Relay segments must not be reachable from corporate IT, vendor remote access paths should be brokered through a jump host with MFA and session recording, and east-west traffic between relay VLANs should be denied by default.
- Disable or restrict unused services. If the relay's web interface or legacy protocols (e.g., Modbus where unused) are not operationally required, disable them per Siemens hardening guidance. Every listening service on a pre-V2.70 device is a potential entry point for the input-validation and memory-corruption flaws.
- Deploy the detection content above. Stand up the Sentinel KQL query and firewall-based Sigma rules today — they cost nothing and provide the tripwire you need during the patch window, which in utility environments can stretch for weeks or months pending outage approvals.
- Inventory and verify. You cannot patch what you haven't counted. Use the verification script (passively where possible) to build a complete list of 7SR5 devices and firmware versions, then track remediation to completion with per-device sign-off.
- Monitor CISA KEV. These CVEs are not in the Known Exploited Vulnerabilities catalog today. If any of them land there, federal deadlines and your own risk-based SLAs kick in immediately — subscribe to KEV and ICS-CERT feeds so you're not finding out from a news article.
Protection relays are the last line of defense between a fault and a blackout. Fourteen CVEs, a 9.8, and missing authentication on a device class that historically lives for 15+ years in the field — this is the kind of advisory where 'we'll get to it next quarter' is the wrong answer. Patch V2.70, segment like you mean it, and watch the wire in between.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.