The short version
On 15 September 2026, CISA republished Schneider Electric notification SEVD-2026-251-03 as ICSA-26-258-04. It covers one CVE, CVE-2026-81861, in the SCADAPack x70 remote terminal units. All versions of the 47x, 47xi, 47xd, 470R, 57x, 3xx and 32 are affected.
The flaw sits in Secure Lock, the legacy password feature. It protects passwords on the wire with keys that are the same on every device. Anyone who captures an unlock or a password change can recover the password.
There is no firmware fix. The fix is configuration: move to Role-Based Access Control (RBAC), segment, and turn on the RTU firewall. Until that is done at every site, the control that helps is deciding who can reach each RTU at all.
What the advisory says.
- Products: SCADAPack 47x, 47xi, 47xd, 470R, 57x, 3xx and 32. All versions.
- The flaw: insufficiently protected credentials (CWE-522). It could expose authentication information and allow unauthorized access to RTU functionality.
- Score: CVSS v3.1 6.5, vector
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. CVSS v4.0 5.9. - Sectors listed: Critical Manufacturing and Energy, deployed worldwide.
- Reported by: Abhinav Agarwal, to CISA.
The vector is worth reading closely. It is network reachable with no privileges, but it needs user interaction (UI:R). Schneider rates the impact as confidentiality only. The password leaks. The flaw does not, by itself, change anything on the RTU.
| Date | Event |
|---|---|
| 16 July 2026 | Researcher reports the issue to CISA |
| 8 September 2026 | Schneider publishes SEVD-2026-251-03 |
| 15 September 2026 | CISA republishes it as ICSA-26-258-04 |
How the attack works.
The researcher's write-up explains the mechanism. Secure Lock wraps lock, unlock and password-change messages with an AES-128 key and an HMAC-SHA256 key. Both keys come from constants compiled into the software. They are identical in the configuration software and in the RTU firmware, with nothing unique per device or per session.
So the protection is the same everywhere. An attacker who can watch the traffic while an engineer sets, changes or uses the password can recover it. The researcher describes this traffic as DNP3 Virtual Terminal messages. That is the user interaction in the score: someone has to log in while the attacker listens.
What leaks is the password itself. The attacker then uses it through the RTU's normal unlock workflow, the same one your engineers use.
The mapping below uses MITRE ATT&CK for ICS. The first and last rows are conditions and follow-on steps, labelled as such. The advisory does not describe them.
| Tactic | Technique (ID) | What it means here |
|---|---|---|
| Initial Access | External Remote Services (T0822) | Conditional: a VPN, vendor tunnel or cellular path that puts an attacker on the network carrying RTU traffic |
| Discovery | Network Sniffing (T0842) | Capturing Secure Lock lock, unlock or password-change messages |
| Persistence, Lateral Movement | Valid Accounts (T0859) | Using the recovered password through the normal unlock workflow |
| Collection | Program Upload (T0845) | Possible follow-on: reading RTU configuration once unlocked, which the advisory names as the risk |
Why it matters for a remote site.
An RTU usually sits where nobody works. It is at a lift station, a well head, a substation or a pipeline valve. It reports back over radio, cellular or a leased line.
That shapes the risk. The path between the control room and the RTU is long, and much of it is out of your hands. Each hop is a place traffic can be watched. And a site visit to change a password is a truck roll.
There is also a time problem. A password that crossed the network under Secure Lock should be treated as known. That holds for every password set or used before the move to RBAC, not only future ones.
What to do this week.
Schneider's steps come first, in the advisory's order.
- Move from Secure Lock to RBAC. Follow the SCADAPack sections "Security Guidelines for Administrators" and "Working with Role-Based Access Control". The advisory says Secure Lock should only stay where a legacy system requires it.
- Segment the network. Restrict traffic between trusted and untrusted networks, so the RTU network is not reachable from the office or the internet.
- Enable the RTU firewall service. Limit which hosts can reach which services on the RTU.
- Apply the SCADAPack Cybersecurity Guide. Read the Hardening and Secured Communication sections and use secured protocols where the RTU and master support them.
Then our additions for the sites where that takes time.
- List every SCADAPack and its lock mode. Model, site, firmware, and whether it runs Secure Lock or RBAC. The sites still on Secure Lock are your work list.
- Change the passwords as part of the move. Assume any Secure Lock password used on the network is known.
- Write down who can reach each RTU. Every engineering laptop, every VPN user, every integrator. Cut the list to the people who do the job.
How a gate helps while reconfiguration is slow.
Moving a fleet to RBAC is real work. Each RTU needs a configuration change, a test, and often a visit. A utility with forty remote sites will not finish this week. That leaves a window where the flaw stays in place.
Access Gate covers that window by controlling who reaches the RTU. It is an on-site appliance that connects to the existing network, beside it. You then steer traffic for the RTUs you want protected through it, one at a time. Nothing is installed on the RTU, and it is installed in a day per site.
With the gate in place, an engineer or integrator who needs the RTU signs in with their own identity and MFA. The gate allows that person to reach that RTU on the protocol the job needs. Every session is recorded. A password recovered from captured traffic is no longer enough on its own: the attacker also needs an identity the gate accepts. See secure remote access for how sessions are brokered.
What Access Gate does not fix. It does not change how Secure Lock protects credentials on the RTU, and it does not replace the move to RBAC. It cannot stop someone capturing traffic on a link outside the gate, such as a radio hop between the master and the RTU. It does not recover a password that has already leaked. It narrows who can use one, and it records who did.
For the protocol side of remote sites, see securing DNP3. For the water and wastewater view, see water and wastewater. To sketch your own sites and where a gate would sit, use Build My Network. Every advisory we have analysed is in the ICS security advisories archive.
Sources: CISA ICS Advisory ICSA-26-258-04 (15 September 2026) and its CSAF record, a verbatim republication of Schneider Electric SEVD-2026-251-03 (8 September 2026); the researcher's write-up by Abhinav Agarwal (10 September 2026); and the CISA Known Exploited Vulnerabilities catalog, checked 1 October 2026. Confirm the procedures against the SCADAPack documentation for your firmware before changing a production RTU.