Executive Summary
CVE-2026-62654 describes a maintenance mode in Reyrolle 7SR5 protection relays, present in all versions below V2.70, that is triggered by a physical key sequence during boot and then downloads and executes program code from a network server without verifying its authenticity or integrity. An attacker with physical access to the relay can therefore push arbitrary unsigned firmware or logic onto a device that trips breakers, giving them direct control over protective functions in a substation.
Technical Exposure Breakdown
The vulnerable component is the boot-time maintenance path in the 7SR5 feeder and overcurrent protection relay. According to the grounding data, this affects all versions prior to V2.70. The attack is not remote in the classic sense. It requires an operator or intruder to hold a defined key combination during the device power-up cycle, which places the relay into a special maintenance mode. In that mode the relay reaches out to a network server and pulls executable program code. The failure is that the code is neither signed nor integrity checked before execution.
The CVSS score of 6.8 reflects the physical-access precondition. That precondition is real but it is not a safeguard in the substation context. Relays sit in bays and cabinets that see contract technicians, commissioning crews, and shared maintenance laptops. Anyone who can reach the front panel during a reboot, and who controls or can reach the code server the relay contacts, can load their own image. The absence of signature validation means the relay treats a hostile server exactly like a legitimate one.
This is a supply-chain and trust-boundary failure inside the device firmware itself. The boot loader trusts whatever it retrieves. There is no cryptographic anchor to distinguish vendor firmware from attacker firmware. Once unsigned code runs on the relay, every downstream assumption about the device behaving as configured is void.
OT Impact and Compliance Risk
A protection relay is the last automated line of defense against fault currents. If an attacker replaces its logic, they can suppress trip commands, force nuisance trips, or alter time-current curves so that faults are not cleared. That translates directly into equipment damage, arc flash exposure to personnel, and cascading outages when coordination is broken across the protection scheme. This is a physical-consequence device, not a data asset.
Under IEC 62443 this is a firmware integrity failure that undercuts the secure-boot and code-authenticity expectations for a component at this criticality level. For utilities under NERC CIP, a relay in an Electronic Security Perimeter with a documented code-execution weakness feeds directly into CIP-007 patch management and CIP-010 configuration and baseline monitoring obligations. Physical access being the vector also puts CIP-006 physical security controls back under scrutiny, because the standard assumption that physical control equals safety does not hold when the boot path trusts an external server. Water and wastewater operators running similar protection assets should treat this under their AWIA 2018 risk and resilience assessments as well.
Compensating Controls
Do not rely on active scanning to find or probe these relays. Aggressive polling of protection devices can disrupt their real-time functions, and there is no reason to touch the boot path with a scanner. Inventory passively and by documentation instead.
- Enforce and log physical access to relay cabinets and bays. Since the trigger is a boot-time key sequence, controlled and witnessed reboots remove the practical attack window.
- Segment relays so they cannot reach an arbitrary code server. The maintenance download depends on network reachability to a server. Restrict that path to a locked-down, authenticated staging host and block all other egress from the relay VLAN at the switch or firewall.
- Deploy a Suricata rule concept that alerts on any relay-sourced file retrieval outside of a scheduled, ticketed maintenance window. Match on the relay source address range initiating outbound code-transfer traffic, and treat any match as an incident since normal operation should not include unscheduled downloads.
- Baseline firmware hashes where the platform exposes them, and alert on any change under CIP-010 configuration monitoring.
- Track vendor guidance for the fixed version and validate the code-authenticity behavior of any update before mass deployment.
The core mitigation is denying the two conditions the attack needs at the same time: physical boot access and a reachable code server. Break either one and the exploit path collapses.
BreachSpider Intel
Intel by BreachSpider tracks CVE-2026-62654 and related protection-relay exposures so OT teams can monitor affected assets and compensating-control status in one place.