Executive Summary
CVE-2026-62648 is a pre-authentication out-of-bounds write in the HTTP handling of Siemens Reyrolle 7SR5 protection relays (all versions below V2.70), triggered when the length of the URL component in an HTTP message is not validated before data is appended to it. An unauthenticated remote attacker can crash the device and force a reboot, removing protective relaying from service during the reboot window on equipment that governs breaker trip decisions in substations.
Technical Exposure Breakdown
The defect sits in the parsing path for HTTP requests reaching the relay web interface. Per the grounding data, the length of the URL component in pre-authenticated HTTP messages is not properly validated before additional data is appended to it, producing an out-of-bounds write in memory. Because the flaw is reachable before authentication, no credentials, session state, or prior device knowledge are required. A single crafted request over the management or engineering interface is sufficient to corrupt memory and induce a crash.
The failure mode here is memory-safety, not logic. An out-of-bounds write means the attacker is placing data past the bounds of an allocated buffer. The disclosed outcome is a crash and reboot, which points to a denial-of-service condition rather than confirmed code execution. That distinction matters for triage, but it does not lower urgency. A relay that reboots on demand is a relay an attacker can hold out of service by repeating the request.
The 7SR5 is a feeder and transformer protection device. Its HTTP service exists for configuration and diagnostics, not for continuous operation. In many deployments that interface should never be exposed to routable networks at all, yet field audits repeatedly find protection relays reachable from engineering VLANs, shared maintenance subnets, and occasionally from segments with indirect internet paths. The precondition for exploitation is simply IP reachability to the HTTP listener.
OT Impact and Compliance Risk
The physical consequence is loss of protection availability. When a 7SR5 reboots, it is not evaluating fault conditions for the duration of the restart. If a fault occurs during that window, backup protection or upstream devices must clear it, typically slower and with wider impact. An attacker who scripts repeated crash requests can suppress a specific protection zone, which is a targeted degradation of the protective scheme rather than a nuisance.
For NERC CIP registered entities, an externally reachable protection relay with a pre-auth DoS is a CIP-005 electronic security perimeter and CIP-007 patch and ports-and-services concern. Under IEC 62443, this maps to failures in resource availability and input validation expectations for zone-and-conduit designs. Operators of covered substations should treat this as an availability event affecting a safety-relevant function, not a low-severity web bug. The CVSS of 7.5 reflects an unauthenticated network-reachable availability impact.
Compensating Controls
Do not run an active scan sweep to inventory affected relays. Aggressive probing of protection devices can itself induce the exact crash this CVE describes, and active scanning has bricked or reset industrial components before. Build your inventory from configuration management records and passive network observation instead.
- Remove the HTTP interface from any routable path. Restrict the relay management port to a dedicated engineering host through an explicit allow-list ACL on the switch or firewall, denying all other sources.
- Place the 7SR5 behind a conduit boundary where a deep-packet-inspection firewall or IPS can enforce HTTP request sanity. A Suricata rule concept: alert on HTTP requests to relay management addresses where the URI length exceeds a defined threshold, then drop those flows inline at the conduit. This is a virtual patch that blocks the oversized-URL trigger without touching the device.
- Rate-limit and log connections to the management interface so repeated reboot attempts surface as an alert rather than silent protection loss.
- Confirm your backup protection coordination assumes a possible primary-relay outage, and rehearse the response for a relay that reboots without an obvious hardware cause.
Validate any V2.70 or later firmware in a maintenance window against your protection settings before field deployment. Patch status for specific builds is not confirmed in the source data.
BreachSpider Intel
BreachSpider tracks CVE-2026-62648 and related protection-relay exposures across its vulnerability dataset for operators who need ongoing monitoring of ICS and OT product risk.