Siemens wrote the Reyrolle 7SR5’s session-token failure as three separate CVEs with three different weakness classes, and for one of them its own CVSS v3.1 and v4.0 vectors disagree on how hard the attack is.
What happened
Siemens ProductCERT published advisory SSA-142885 on Tuesday, September 8, 2026, at version 1. It covers the Reyrolle 7SR5, a digital protection relay used in electrical substations, in all versions before V2.70. The fix is V2.70 or later.
The advisory’s machine-readable CSAF document enumerates 14 CVEs. Five are from 2024 and belong to the Cesanta Mongoose embedded web server: CVE-2024-42384, CVE-2024-42385, CVE-2024-42386, CVE-2024-42391, and CVE-2024-42392, all describing memory or parsing faults in Mongoose v7.14. The other nine were assigned in 2026 and are Siemens’ own.
Three of those nine describe the same broken thing from three angles.
CVE-2026-62645, CWE-306, scored 9.8 under CVSS v3.1 and 9.3 under v4.0: “Information is exposed through the web interface that can be used to calculate the current and past session ID numbers. This could allow an attacker to bypass the authentication and gain unauthorized access to the device.”
CVE-2026-62646, CWE-331, scored 7.4 under v3.1 and 9.1 under v4.0: “A session identifier is generated using an algorithm with insufficient randomness, resulting in a token with low entropy that can be predicted or brute-forced within a feasible number of attempts. This could allow an unauthenticated remote attacker to derive valid session identifiers and bypass authentication.”
CVE-2026-62647, CWE-20, scored 7.4 under v3.1 and 9.3 under v4.0: “A random number generator is used to generate security-relevant values (such as session identifiers used for authentication purposes) that is not initialized with a True Random Number Generator (TRNG), resulting in a predictable sequence of generated values.”
The v3.1 vector for CVE-2026-62647 is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. The v4.0 vector for the same CVE, from the same source, in the same advisory, is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Attack complexity is H in one and L in the other. The result is 7.4 High and 9.3 Critical for one flaw.
The rest of the 2026 set: CVE-2026-62650 (8.8, CWE-288) lets an authenticated low-privileged user escalate to administrator by manipulating request data, because server-side authorization checks in the web interface are not properly enforced. CVE-2026-62648 (7.5, CWE-787) is an out-of-bounds write from an unvalidated URL length in pre-authenticated HTTP messages, and CVE-2026-62649 (7.5, CWE-770) is unbounded resource use under concurrent HTTP requests; both let an unauthenticated remote attacker “crash the affected device, causing a reboot.” CVE-2026-62652 (5.3) is unstripped debugging symbols in publicly downloadable firmware. CVE-2026-62653 and CVE-2026-62654 (6.8 each) require physical access: the second says a “special maintenance mode can be activated via a physical key sequence during device boot, in which the device downloads and executes program code from a network server without verifying its authenticity or integrity.”
The advisory documents no workaround. Under general recommendations, Siemens writes: “Operators of critical power systems (e.g. TSOs or DSOs) worldwide are usually required by regulations to build resilience into the power grids by applying multi-level redundant secondary protection schemes. It is therefore recommended that the operators check whether appropriate resilient protection measures are in place. The risk of cyber incidents impacting the grid’s reliability can thus be minimized by virtue of the grid design.”
Why it matters
Start with that last quotation, because it is the most candid sentence in the advisory. Siemens is pointing operators at grid design as the compensating control. Read against CVE-2026-62648 and CVE-2026-62649 — two ways for an unauthenticated attacker on the network to make the relay crash and reboot — it is Siemens saying that the answer to a protection relay dropping offline is that the protection scheme should not depend on one relay. That is correct engineering advice. It is also an admission about what the failure mode of these two CVEs actually is, stated more plainly than the 7.5 availability score conveys.
The three session CVEs are the more interesting artifact. They are not duplicates: an information leak that lets you calculate the token, a generator with too little entropy, and an RNG never seeded from a hardware source are three distinct defects. But they stack into one outcome, which is that the relay cannot issue a session token an attacker cannot obtain. Siemens split them, assigned three weakness classes, and scored them 9.8, 7.4, and 7.4.
What a scanner does with that is report three findings at two severities against one device that needs one update. The organization then has a queue in which the 9.8 gets a ticket this week and the two 7.4s get a ticket next quarter, even though V2.70 closes all three and there is no partial remediation available. Splitting a single root cause across several records is defensible practice for a CNA, but it interacts badly with tooling that treats each record as an independent unit of work.
The attack-complexity split on CVE-2026-62647 is a cleaner problem. Attack complexity means roughly the same thing in both frameworks: conditions outside the attacker’s control that must hold for the attack to work. Whether a predictable RNG sequence requires such conditions is a judgment call, and reasonable people land on either side of it. What is not reasonable is landing on both sides in the same document. A v3.1 shop reads High. A v4.0 shop reads Critical. Neither is misreading the advisory; the advisory says both.
This matters more than the 1.9-point gap suggests, because the migration from v3.1 to v4.0 is still in progress across the industry, and organizations are increasingly comparing notes with peers, regulators, and insurers who may be on the other framework. When two parties disagree about a relay’s risk and both are quoting the vendor correctly, the disagreement is unresolvable by reading the source. It has to be resolved by asking which framework each number came from — a question that almost never gets asked because everyone assumes a CVSS score is a CVSS score.
The five 2024 Mongoose CVEs are the ordinary latency of embedded firmware rather than a scandal, but they carry information. They tell anyone reading the advisory that the Reyrolle 7SR5 shipped Mongoose v7.14 or older, which is a fact an attacker did not have on Monday. CVE-2026-62652, the unstripped debugging symbols in publicly downloadable firmware, compounds that: the internals of this device should now be treated as known to anyone who wants to know them.
CVE-2026-62654 is the one worth sitting with. A physical key sequence at boot puts the relay into a mode where it fetches and runs unsigned code from a network server. It scores 6.8 because CVSS treats physical access as expensive. In a substation that assumption mostly holds. It holds less well during commissioning, during vendor maintenance, and anywhere in the supply chain before the device reaches the substation — which is exactly where an unsigned-code path is most valuable to an attacker and least visible to the operator.
What to do
Update the Reyrolle 7SR5 to V2.70 or later. Siemens points to support.industry.siemens.com item 109772413 for the update, and documents no workaround for any of the 14 issues. Because one update closes all of them, there is no partial path and no reason to sequence the session CVEs against each other.
Until the update lands, the only available control is reachability. Confirm which networks can reach the 7SR5 web interface today — station bus, engineering VLAN, remote access path, anything routable — and reduce that set. CVE-2026-62648 and CVE-2026-62649 need no credentials, and CVE-2026-62645 needs none either.
Check the redundancy assumption Siemens is relying on rather than assuming it. If a single 7SR5 rebooting removes protection from a feeder with no backup scheme covering that window, the advisory’s general recommendation is not satisfied on your system, and that is a finding independent of the patch.
When comparing this advisory’s severity against anyone else’s numbers, record which CVSS version produced each score. For CVE-2026-62647 specifically, expect to see both 7.4 and 9.3 quoted, both correctly, and do not treat the difference as evidence that someone got it wrong.
Sourcing note
Checked: the CSAF JSON for SSA-142885 at cert-portal.siemens.com/productcert/csaf/ssa-142885.json, which is the machine-readable form of the advisory and the authority used here for the CVE list, weakness classes, and v3.1 vectors; the HTML rendering of the same advisory for the vulnerability descriptions and general recommendations quoted above; and the NVD API and CVE Program API records for CVE-2026-62645, CVE-2026-62646, and CVE-2026-62647, which supplied the CVSS v4.0 vectors and agree with the advisory on descriptions and v3.1 vectors.
Discrepancy noted: an earlier read of the HTML advisory returned a count of 15 vulnerabilities. The CSAF document enumerates 14. The CSAF count is used here. Separately, the 2026 identifier block in this advisory runs CVE-2026-62645 through CVE-2026-62654 with CVE-2026-62651 absent; that identifier returns no record in NVD, and Siemens does not explain the gap.
Could not reach: CISA’s ICS advisory pages, which return 403 to automated fetching, so whether CISA has republished SSA-142885 as an ICS advisory is unverified as of this writing.
Unresolved: no exploitation of any of these CVEs has been reported, and none appears in CISA’s Known Exploited Vulnerabilities catalog. Siemens does not state how the flaws were found or by whom. The advisory does not say how many session-ID bits the generator produces or how many attempts “a feasible number” means, so the practical cost of the brute force in CVE-2026-62646 is not publicly quantified.