A server login can alter grid control room data without the control system's own password.

Anyone holding an ordinary login on the Windows server that hosts a widely deployed control room system for electricity networks can read and change the configuration that system runs on, without ever signing in to the control system itself. The vendor, Hitachi Energy, states this in its own advisory, which the US cyber security agency CISA republished unchanged on 20 October.

The product sits in control rooms at transmission and distribution utilities, and at industrial operations large enough to run their own networks. The vendor records it as deployed worldwide, in the energy sector.

Two further weaknesses are described alongside it. One lets a person who already has the engineering tools take full administrative control of the Windows machine underneath them. The other turns a log exported for review into a route for running code on the computer of whoever opened it.

None of the three is reachable from the internet. Each needs a foothold on the server or in the engineering tooling first. That makes this a question about who holds accounts rather than about the perimeter, and the people to pass it to are whoever maintains the control room software and whoever signs off its user list.

What it changes in the control room

MicroSCADA X SYS600 is the layer between the people in a control room and the plant. It holds the live picture, the mimic, the control room's working diagram of breakers and feeders, and it carries operator commands back out to the network. The objects it holds are the configured points: a breaker here, a transformer there, a measurement, each with rules about who may touch it. The vendor's stated position is that only accounts belonging to the control system should be able to see or change those objects.

The finding is that a login on the host operating system is sufficient instead. A contractor account opened for a patching window, a service account nobody has reviewed in three years, a Windows administrator who was never meant to be an operator: on the vendor's description, each of those can read and change the configured points while appearing nowhere in the control system's own list of users.

That lands in two commercial places. The first is audit. Where the control system's user list is the evidence an operator presents for who can change the grid picture, that evidence is describing a smaller set of people than the ones who can actually do it. The second is confidence in the display. The practical reading is that a changed point is not an outage and will not announce itself as one: the control room carries on working, and the question of whether the diagram still matches the plant becomes a question somebody has to go and answer physically.

The privilege escalation sits next to this and compounds it. A person given the engineering tools, typically an integrator or a configuration engineer rather than an operator, can on the vendor's account become administrator of the host. The spreadsheet issue is the quietest of the three and the one most likely to catch somebody at a desk: text written into a log as a formula runs when that log is exported and opened, and the vendor records every Windows user who can run its notification service and export a log as exposed, whatever their privilege level.

The questions this puts to suppliers

The remediation is not uniform across the three, and that is the detail worth carrying into the conversation. For two of them, a newer release is the vendor's fix. For the authentication weakness, the vendor pairs the newer release with a configuration step set out in its installation and administration manual and its deployment guide, and it still lists that newest release as affected where the step is not applied.

So the question for whoever holds the maintenance contract is not only whether an upgrade is scheduled. It is whether the configuration work that accompanies it is in the same scope of work, because on the vendor's own table the upgrade alone does not close that one.

A second question goes to whoever administers the host: who currently holds an operating system account on that server, and does that list match the list of people the organisation believes can change the grid picture. Many sites have treated those as one question. This advisory separates them.

A third is for the integrator: whether the engineering tools are installed on machines whose users are not intended to be administrators of the host, and what is relied on to keep those two things apart. The vendor's record showed no observed exploitation when the advisory was scored in late September, which bears on how urgently the window is booked rather than on whether the work is needed; the document closes with the usual segmentation and remote-access guidance.

The technical record

Advisory: CISA ICSA-26-293-04, released 20 October 2026, revision 3, a republication of Hitachi Energy PSIRT 8DBD000249 converted from the vendor's CSAF file. Vendor initial release 1 September 2026; revision 2, on 29 September 2026, added researcher credit. CISA has republished this unchanged, so Hitachi Energy is the authority here and the place to watch for revisions.

Product: MicroSCADA X SYS600. Affected: versions 10.7 and prior for all three issues, and version 10.8 for CVE-2026-9853, listed as known affected with mitigation entries only.

CVE-2026-9853, CWE-303: a user authenticated to the host operating system can read and change application objects without an authenticated SYS600 session. CVSS v3.1 7.8 high, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H; CVSS v4.0 8.5 high.

CVE-2026-9854, CWE-303: access to the engineering tools permits elevation to administrator on the underlying Windows host. CVSS v3.1 7.8 high, same vector; CVSS v4.0 8.5 high.

CVE-2026-9852, CWE-1236: CSV formula injection via log content, requiring the ability to write arbitrary log messages, by SCIL scripting, a log injection flaw, or the SYS600 broker. CVSS v3.1 5.0 medium, CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N; CVSS v4.0 4.6 medium.

Remediation: update to 10.8 for CVE-2026-9852 and CVE-2026-9854. For CVE-2026-9853, update to 10.8 and apply the mitigation strategy in the 10.8 installation and administration manual, section 2.1.7.5, recorded as available for versions 10.3 onwards, with the 10.8 cybersecurity deployment guide referenced alongside.

Document note: the header counts two vulnerabilities and shows one v3 score of 7.8, while three identifiers are described and CVE-2026-9853 appears twice in the affected-versions line. Exploitation: SSVCv2/E:N/A:N, dated 28 September 2026. Reported to CISA by researchers at Sandia National Laboratories under its CyTRICS programme.

The ordinary shape of an advisory is that a version number resolves it. This one breaks that shape on its most serious finding: the current release remains listed as affected unless a step from a configuration manual has been applied as well. An operator reading only the version column would record this as closed and have the paperwork to prove it.