The September 8 Siemens ProductCERT advisory, SSA-142885, was republished by CISA on September 15. It applies to every identified 7SR5 firmware release below V2.70, rather than a narrow subset of relay variants or configurations. For substation operators, this is a device-level security update with operational consequences: the web interface is part of the exposed management plane for equipment that participates in protection and automation workflows.
CISA’s CVE enrichment for CVE-2026-62645 records no known exploitation at publication. That should not be mistaken for a low-risk condition. The disclosed attack path is network-based, requires no credentials and no user interaction, and the vendor’s scoring assigns high impact to confidentiality, integrity, and availability. Organizations that have allowed relay management interfaces to cross poorly segmented OT and IT boundaries have a concrete exposure to investigate before scheduling the firmware work.
V2.70 closes more than a third-party component issue
Five of the listed CVEs—CVE-2024-42384, CVE-2024-42385, CVE-2024-42386, CVE-2024-42391, and CVE-2024-42392—originate in Cesanta Mongoose Web Server version 7.14. Those vulnerabilities were publicly assigned in November 2024 and include malformed TLS and certificate-input conditions that can cause crashes, out-of-bounds memory access, or an infinite loop.
Siemens’ inclusion of those older Mongoose issues in the 7SR5 advisory establishes an important deployment fact: the vulnerable web-server code was present in affected Reyrolle firmware until this release. A management workstation that can reach the relay’s web service is therefore relevant to the risk assessment even when the relay has no direct route to the public internet.
The more consequential portion of SSA-142885 consists of nine CVEs assigned in 2026. Several concern how the appliance establishes and protects authenticated web sessions. CVE-2026-62645 exposes enough information through the web interface to calculate current and previous session-ID values. CVE-2026-62646 describes session IDs with insufficient randomness that can be predicted or feasibly brute-forced, while CVE-2026-62647 concerns predictable security-relevant values generated without a true random-number generator.
These are separate records, but they point to the same operational concern: a web-management session must be considered a security boundary. If session material is predictable or exposed, a password alone does not provide the protection administrators expect. Siemens rates CVE-2026-62645 as critical; the related entropy and random-number issues receive lower CVSS v3.1 scores, but can still support unauthorized access under the conditions described by the vendor.
The remote risks are concentrated in the web interface
Other V2.70 fixes cover unauthenticated denial-of-service conditions in HTTP request handling. CVE-2026-62648 is an out-of-bounds write caused by inadequate validation of a URL component in pre-authenticated HTTP messages; Siemens says it can crash and reboot the affected device. CVE-2026-62649 concerns insufficient resource management under a high volume of concurrent HTTP requests and can similarly make the entire device crash and restart.
For a conventional server, a restart is often a capacity incident. For a protection relay, the immediate outcome has to be assessed alongside the site’s protection architecture, relay role, failover arrangements, alarm handling, and maintenance procedures. Siemens’ advisory expressly advises transmission and distribution system operators to verify resilient, multi-level redundant protection arrangements. That recommendation is useful, but it is not a substitute for fixing the management service.
The advisory also lists CVE-2026-62650, CVE-2026-62652, and CVE-2026-62653, covering alternate authentication paths, debug information exposure, and input-validation weaknesses. The affected firmware range is identical across the advisory, making partial remediation impractical: an operator cannot meaningfully address the critical authentication problem while remaining on a pre-V2.70 build and claim the device is fully remediated.
One remaining issue has a different threat model. CVE-2026-62654 requires physical access and a special key sequence during boot to place the relay in a maintenance mode that downloads and executes code from a network server without verifying authenticity or integrity. Siemens rates that flaw medium because the attack vector is physical, but its impact is severe in environments where cabinets, local engineering access, or maintenance networks are not tightly controlled. This is the kind of finding that should prompt a review of physical access controls and maintenance-port procedures alongside the firmware update.
What Windows and OT administrators should do now
The practical first step is inventory, not indiscriminate rebooting. Many organizations will find the relevant management path from a Windows engineering workstation, jump host, or vendor configuration environment rather than from the relay itself. Inventory records should capture the precise 7SR5 firmware version, device location and role, current web-management exposure, and the workstation or subnet permitted to administer it.
Before deploying V2.70, operators should complete a change plan that treats the relay as operational technology rather than a routine endpoint:
- Confirm that each Reyrolle 7SR5 instance is running V2.70 or later; every firmware release below V2.70 is in scope.
- Remove any direct internet exposure of relay web interfaces and restrict access to approved engineering workstations through OT firewalls, access-control lists, and segmented management networks.
- Review remote-access paths from Windows jump servers, VPN concentrators, vendor-support connections, and dual-homed engineering laptops, because the disclosed critical flaw targets the relay’s web interface rather than a Windows component.
- Validate the firmware procedure on representative equipment, confirm rollback and recovery arrangements, and coordinate timing with protection engineers who understand the consequence of a reboot or configuration error.
- Confirm that backup protection, redundancy, and alarm monitoring remain available during each maintenance window.
- Preserve configuration backups and document pre- and post-update firmware versions, access-control settings, and validation results for audit and incident-response purposes.
Siemens recommends applying the update with its documented tooling, validating it before broad deployment, and supervising the process with trained staff. The vendor also says automated deployment may be used where the product supports it. That language does not establish that every 7SR5 estate can be updated centrally; administrators should verify tooling compatibility and the actual update workflow for their installed relay fleet before assuming a Windows-based management platform can push the firmware unattended.
What Siemens and CISA have not established
The public material provides a clear fixed version and an unusually broad affected range, but it leaves several operational questions unanswered. Siemens does not publish a public estimate of affected deployments, identify sectors or regions using vulnerable firmware, or state whether any of the flaws were found in customer environments. It also does not provide a public technical changelog explaining which code paths V2.70 changes beyond the CVE descriptions.
Likewise, CISA’s republication does not establish that an exploit is circulating, that any utility has been compromised, or that the affected relays are broadly internet-exposed. It repeats Siemens’ advisory through CISA’s industrial-control-system channel and emphasizes familiar controls—minimize exposure, isolate control networks, and use secured remote access—but those controls reduce reachability rather than remove vulnerable firmware.
The distinction matters during triage. A relay isolated behind a properly administered OT boundary has a smaller immediate remote attack surface than one reachable from corporate networks or vendor remote-support infrastructure. Yet segmentation does not resolve the session-prediction problems, HTTP crash paths, or physical maintenance-mode weakness; it only narrows who can attempt them.
Reyrolle 7SR5 operators should therefore make V2.70 the remediation target, while using network restrictions and physical-access controls to reduce exposure during the maintenance window. The durable outcome is a documented firmware baseline at V2.70 or later and a management design in which relay web interfaces are reachable only from controlled engineering paths.