CISA: ABB PCM600 scheduler hands local users SYSTEM
The fix is a Windows Log On tab, not a patch: ABB's own workaround for the LocalSystem privilege escalation is to reconfigure the service by hand.
TL;DR
CISA published ICSA-26-274-03 covering two flaws in ABB Protection and Control IED Manager PCM600 2.14 and earlier, deployed in energy infrastructure worldwide. CVE-2026-15952 (CVSS v3.1 6.4, v4.0 7.1) lets any local user with valid credentials escalate privileges because the ABBPCMSchedulerService runs as LocalSystem while granting permissions to the local users group; CVE-2026-15953 is a path traversal in project archive extraction. ABB's remediations are workarounds. The advisory lists no fixed version. CISA reports no known public exploitation.
CISA's Tuesday advisory on ABB's Protection and Control IED Manager PCM600 reads like a permissions audit nobody ran. CVE-2026-15952 is a textbook privilege escalation: the ABBPCMSchedulerService that ships with PCM600 executes under the LocalSystem account, while permissions on the service are granted to standard PCM600 users through membership in the local users group. Anyone holding valid credentials on the host can therefore elevate to SYSTEM and take the machine. CVSS v4.0 scores it 7.1 High; v3.1 puts it at 6.4 Medium, the difference being whether you weight the high-privileges-required vector or the blast radius.
CVE-2026-15953 is the second half. PCM600 project archives get extracted without sufficient validation of entry paths, which is to say the Zip-Slip pattern: a "../" in an archive entry writes files anywhere the process can reach. The advisory gives no fixed version for either flaw, no patch date, and no roadmap. ABB lists mitigations and says plainly that the workaround "does not correct the underlying vulnerability."
The remediation is a control-panel setting
What ABB actually asks of operators is manual service reconfiguration. Open services.msc, find the ABBPCMSchedulerService instance for the installed PCM600 version, go to the Log On tab, and point it at the same Windows account that runs PCM600, making sure that account holds "Log on as a service." Two further notes: when IED authentication is enabled, the Scheduler tool must run under that same account, and the PCM600 setting "Always trust IED security certificates" should be enabled only where PCM600-to-IED traffic sits in a trusted environment.
For a facility engineer, that's Monday morning's work: inventory every PCM600 host, check the service logon account on each, and confirm no one left a shared engineering account in the local users group. For the compliance program, it's a change to a production OT workstation that hasn't been tested against connected relays, which is precisely how ICS patching stalls.
The recurring class
The scheduler flaw sits inside a pattern that is now several advisories deep. ICSA-26-120-02, published April 30, covered a path traversal in the SharpZip.dll bundled with PCM600 1.5 through 2.13, corrected in 2.14 (which is still affected by today's pair). Hitachi Energy's advisory ICSA-26-125-01 carried the same CVE across its PCM600 3.x line, where the vendor said plainly that it cannot stand behind the 2.x releases it no longer maintains. Cleartext IED credentials in the PCM600 database landed in 2022 at CVSS 7.1; a certificate-validation bypass in PCM600 Update Manager landed in 2021, found by a Department of Energy CyTRICS researcher at Idaho National Laboratory.
What ties them is that PCM600 is trusted vendor software sitting between an engineering workstation and protective relays, and it has consistently been built with more authority than the surrounding controls recognize. Overprivileged service accounts, extracted archives, credentials on disk. Each advisory treats its CVE as an incident; the file is a design review that hasn't happened.
What the advisory doesn't say
No patch exists in the document, so the mitigation controls exposure and nothing more. CISA reports no known public exploitation specifically targeting these vulnerabilities as of publication. The line that matters to a risk owner is the one about the fix not existing: workarounds here are the whole program until ABB publishes 2NGA003170 and 2NGA003179 successors with version numbers attached.
Published ·Deep Fathom