Schneider SCADAPack x70 RTUs hit by credential flaw across all versions
No firmware fix is offered, the mitigation is to disable the legacy Secure Lock feature and migrate to RBAC, which is a field-engineering project touching every deployed RTU.
TL;DR
CISA published an advisory for CVE-2026-81861 (CVSS 6.5), an insufficiently protected credentials vulnerability in Schneider Electric SCADAPack x70 Remote Terminal Units. All versions of seven product families (47x, 47xi, 47xd, 470R, 57x, 3xx, and 32) are affected across critical manufacturing and energy infrastructure worldwide. The advisory directs users to disable the legacy Secure Lock authentication mechanism and implement Role-Based Access Control instead, along with network segmentation and RTU firewall configuration. No patch is listed; the remediation pathway is architectural, not a firmware update.
Schneider Electric's SCADAPack x70 RTU line has another vulnerability, and this time the fix isn't a software download.
CVE-2026-81861, disclosed Tuesday by CISA, is a credentials-protection flaw in the Secure Lock authentication mechanism used across all seven SCADAPack x70 product families. The affected models (47x, 47xi, 47xd, 470R, 57x, 3xx, and 32) span the entire deployed base. Exploitation could expose authentication information and grant unauthorized access to RTU configuration and control functions, though the confidentiality-only impact keeps the CVSS at a moderate 6.5.
What distinguishes this advisory from the prior SCADAPack x70 notices this year is what's missing: a firmware patch. The March 2026 Modbus TCP flaw (CVE-2026-0667, CVSS 9.8) affecting the same product line shipped with a fix in firmware version 9.12.2 and RemoteConnect R3.4.2. The January 2025 deserialization vulnerability (CVE-2024-12703) was also resolved with a RemoteConnect update [1]. For CVE-2026-81861, Schneider Electric's advisory points to mitigation alone.
The Secure Lock problem
The remediation language is blunt: RBAC is "the recommended access control mechanism" and Secure Lock "is legacy functionality retained for backward compatibility." Users are directed to "use RBAC in place of the Secure Lock feature." This isn't a temporary workaround awaiting a patch, the framing treats RBAC migration as the permanent answer, which means Secure Lock deprecation is the safer read on where this is headed.
That creates real work. Disabling Secure Lock and standing up RBAC means touching each RTU's configuration. It requires planning access-control models, assigning roles, and deploying the new scheme across the fleet. The advisory also calls for network segmentation between trusted and untrusted networks and enabling the RTU firewall service, both of which land on OT network architecture staff, not the vulnerability-management team.
Who feels this Monday
Brownfield deployments in critical manufacturing and energy facilities account for most of the installed base. For defense contractors running SCADAPack units in facility management or test-range SCADA environments, the migration may require system security plan review, change-control documentation, and validation testing before touching production RTUs.
The work is proportional to the deployment footprint. A site with half a dozen RTUs can handle this in a maintenance window. A utility or manufacturer with hundreds of units across distributed sites is looking at a sustained engineering project, and one that competes with the other SCADAPack remediation backlogs already in the queue from the January and March advisories.
Whether Schneider Electric eventually ships a firmware-based fix for CVE-2026-81861 remains an open question. The advisory text doesn't close the door on one, but it also doesn't mention a timeline. Until then, every affected RTU running Secure Lock needs a configuration change.
Published ·Deep Fathom