CVE-2026-81861: Schneider Electric SCADAPack x70 RTU Secure Lock Weakness — Detection and Mitigation Guide (ICSA-26-258-04)

CISA has published ICS advisory ICSA-26-258-04 covering CVE-2026-81861, a vulnerability affecting Schneider Electric's SCADAPack x70 family of Remote Terminal Units (RTUs). These devices are the workhorses of remote monitoring and control in oil and gas, water/wastewater, and utility environments — they sit at unmanned wellheads, pumping stations, and substations bridging the physical process to your SCADA network. The weakness at issue involves the Secure Lock functionality, and failure to apply the vendor's mitigations increases the risk of unauthorized access to RTU configuration, with a primary impact of loss of confidentiality.

That last phrase deserves attention. A confidentiality loss against an RTU's configuration is not a paperwork problem — configuration disclosure hands an adversary the engineering logic, communication parameters, I/O mappings, and potentially credentials or network topology details embedded in the device. In my IR experience with OT intrusions, configuration theft is the reconnaissance phase that precedes destructive manipulation. Treat this advisory accordingly, even though the stated impact is confidentiality rather than direct control.

Technical Analysis

Affected Products and Versions

Per the advisory, all versions of the following products are affected:

The vers:all/* notation in the CSAF data is important: there is no "safe" firmware train to fall back to. Every deployed SCADAPack x70 unit in your fleet is in scope until mitigations are applied.

How the Weakness Works (Defender's View)

The Secure Lock functionality is intended to restrict configuration access on the RTU — think of it as a logical padlock on the engineering interface so that field configuration can't be altered or read by unauthorized parties. CVE-2026-81861 undermines that control: the Secure Lock mechanism does not fully protect the RTU configuration as designed, meaning an attacker who can reach the device's management plane may be able to access configuration data the operator believed was locked down.

Key exploitation characteristics to factor into your risk model:

• Attack vector is the management/configuration plane. SCADAPack units typically expose configuration services over IP — the engineering/configuration interface, and depending on deployment, legacy cleartext services such as Telnet or FTP, alongside industrial protocols like Modbus/TCP (port 502) and DNP3 (port 20000).
• No authentication strength compensates for a broken control. Because the weakness is in the Secure Lock mechanism itself, organizations that assumed "the device is locked, therefore configuration is protected" carry residual risk until mitigations are in place.
• The impact is confidentiality of configuration. Expect exfiltrated configuration to include I/O mappings, logic, communication parameters, and network details — precisely the material an adversary needs to plan follow-on manipulation of the process.
• Reachability is the gating factor. RTUs reachable from IT networks, flat OT segments, or — worst case — the public internet are the highest-risk population. Internet-exposed SCADAPack interfaces are discoverable via internet-scanning services and should be treated as an emergency.

The advisory does not publish a CVSS vector in the summary data; consult the Schneider Electric security notification referenced in ICSA-26-258-04 for the authoritative scoring and the CSAF machine-readable document for structured mitigation details.

Exploitation Status

As of this writing, there is no confirmed in-the-wild exploitation of CVE-2026-81861, no public proof-of-concept code, and the CVE has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. This is a vendor-disclosed weakness published through the coordinated CISA ICS advisory process. That is the time to move — ICS vulnerabilities with published advisories historically see proof-of-concept development and scanning activity within weeks of disclosure, and all-versions-affected advisories on field-deployed RTUs have long remediation tails. Do not wait for KEV inclusion as your trigger.

Detection & Response

The mitigation path for this CVE is primarily configuration-based and compensating-control-based, which means your detection strategy carries the weight until mitigations are verified across the fleet. The goals: (1) inventory every SCADAPack x70 unit and its exposure, (2) detect any non-engineering-station interaction with RTU configuration and management services, and (3) alert on sensitive industrial-protocol function codes that indicate configuration reads/writes.

Sigma Rules

---
title: Unauthorized Host Accessing SCADAPack RTU Management Interface
id: 3f8a1d42-7c55-4e2b-9a61-8d4c2e7f1093
status: experimental
description: Detects network connections to SCADAPack x70 RTU management and configuration services (Telnet, FTP, HTTP/HTTPS config interface) from hosts outside the approved engineering station allowlist. Relevant to CVE-2026-81861 where the Secure Lock control may not protect RTU configuration.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-04
  - https://attack.mitre.org/techniques/T0855/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.discovery
  - attack.t0855
  - attack.t1046
logsource:
  category: firewall
detection:
  selection:
    dst_port:
      - 21
      - 23
      - 80
      - 443
    dst_ip|cidr:
      - '10.10.0.0/16'  # REPLACE: your OT/RTU subnet(s)
  filter_engineering_stations:
    src_ip|cidr:
      - '10.10.1.0/28'  # REPLACE: approved engineering workstation segment
  condition: selection and not filter_engineering_stations
falsepositives:
  - NMS polling of device web interfaces; allowlist known monitoring hosts
level: high
---
title: Unexpected Endpoint Process Communicating Over DNP3 or Modbus Ports
id: 91b6e057-2a34-4d8f-b3c9-5e1a7f42d860
status: experimental
description: Detects processes on engineering workstations or servers initiating connections to DNP3 (20000) or Modbus/TCP (502) ports that are not the approved SCADA configuration or HMI software. May indicate unauthorized tooling used to interrogate SCADAPack RTUs affected by CVE-2026-81861.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-04
  - https://attack.mitre.org/techniques/T0885/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.collection
  - attack.t0885
  - attack.t0801
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort:
      - 20000
      - 502
    Initiated: 'true'
  filter_approved_tools:
    Image|endswith:
      - '\RemoteConnect.exe'   # Schneider SCADAPack x70 configuration tool
      - '\ClearSCADA.exe'      # Example HMI/SCADA master - REPLACE with your approved tools
  condition: selection and not filter_approved_tools
falsepositives:
  - OT vulnerability scanners and asset inventory tools; allowlist by binary hash where possible
level: high
---
title: Sensitive DNP3 Function Code Observed Against RTU Assets
id: 5c2d9a84-8f17-4b63-a7e2-6d3b1c58f024
status: experimental
description: Detects DNP3 requests carrying configuration-affecting function codes (WRITE, SAVE_CONFIGURATION, COLD/WARM RESTART, INITIALIZE_DATA) in Zeek DNP3 logs. In environments where CVE-2026-81861 is unmitigated, unexpected configuration interaction with SCADAPack RTUs is a high-fidelity signal of unauthorized access.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-258-04
  - https://attack.mitre.org/techniques/T0855/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.impact
  - attack.t0855
  - attack.t0831
logsource:
  product: zeek
  service: dnp3
detection:
  selection:
    fc_request:
      - 'WRITE'
      - 'SAVE_CONFIGURATION'
      - 'COLD_RESTART'
      - 'WARM_RESTART'
      - 'INITIALIZE_DATA'
  filter_approved_masters:
    id.orig_h:
      - '10.10.1.10'  # REPLACE: approved SCADA master / engineering station IPs
  condition: selection and not filter_approved_masters
falsepositives:
  - Scheduled maintenance windows and commissioning activity; suppress by change ticket window, not permanently
level: critical

KQL (Microsoft Sentinel)

This query hunts your ingested firewall/CEF telemetry for any source touching SCADAPack-relevant ports that has not been seen doing so historically — surfacing new, unauthorized configuration-plane access without drowning you in routine master-station polling.

// Hunt: new/rare sources interacting with SCADAPack RTU management or industrial protocol ports
// Tune the allowlist and subnets to your OT environment before deploying as an analytic rule
let OT_RtuSubnets = dynamic(["10.10.0.0/16"]);        // REPLACE: your RTU subnets
let ApprovedStations = dynamic(["10.10.1.10", "10.10.1.11"]); // REPLACE: engineering stations / SCADA masters
let IcsPorts = dynamic([21, 23, 80, 443, 502, 20000]);
let lookback = 14d;
let baseline =
    CommonSecurityLog
    | where TimeGenerated between (ago(30d) .. ago(lookback))
    | where DestinationPort in (IcsPorts)
    | where ipv4_is_in_any_range(DestinationIP, OT_RtuSubnets)
    | summarize by SourceIP;
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where DestinationPort in (IcsPorts)
| where ipv4_is_in_any_range(DestinationIP, OT_RtuSubnets)
| where SourceIP !in (ApprovedStations)
| where SourceIP !in (baseline)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            ConnectionCount = count(), PortsTargeted = make_set(DestinationPort),
            Actions = make_set(DeviceAction)
    by SourceIP, DestinationIP, DeviceVendor, DeviceProduct
| order by FirstSeen asc;

If you ingest Sysmon from engineering workstations, pair this with a DeviceNetworkEvents variant filtering on InitiatingProcessFileName !in~ ("RemoteConnect.exe", "<your approved tools>") and RemotePort in (502, 20000).

Velociraptor VQL

Run this hunt across engineering workstations and OT jump hosts to identify unexpected processes holding connections to RTU industrial-protocol or management ports — the telltale of unauthorized configuration tooling running where it shouldn't.

-- Hunt: unauthorized processes communicating with SCADAPack RTU ports
-- Deploy against engineering workstations, HMI servers, and OT jump hosts
SELECT Pid, Ppid, Name, Exe, Username, CommandLine,
       netstat.Raddr.IP AS RemoteIP,
       netstat.Raddr.Port AS RemotePort,
       netstat.Status AS ConnState
FROM pslist()
JOIN netstat() ON Pid = netstat.Pid
WHERE netstat.Raddr.Port IN (21, 23, 80, 443, 502, 20000)
  AND netstat.Status = 'ESTABLISHED'
  AND NOT Exe =~ '(?i)RemoteConnect|ClearSCADA|your_approved_tool'
  AND netstat.Raddr.IP =~ '^10\\.10\\.'   // REPLACE: your RTU subnet pattern

Discovery and Exposure Audit Script

Because every version is affected, step one is knowing exactly where your SCADAPack x70 units live and what services they expose. Run this from an OT monitoring host or jump box with authorization — it inventories RTU-like services and flags dangerous exposure (Telnet/FTP enabled, management interfaces reachable).

#!/bin/bash
# scadapack-exposure-audit.sh
# Discovers potential SCADAPack x70 RTUs and audits exposed management services.
# Run ONLY against subnets you are authorized to scan. Use -T2 and low rates
# on OT segments to avoid impacting field devices.
# Usage: ./scadapack-exposure-audit.sh 10.10.0.0/16

TARGET="${1:?Usage: $0 <target-subnet>}"
TS=$(date +%Y%m%d-%H%M%S)
OUT="scadapack_audit_${TS}"

# 1) Identify hosts exposing RTU-relevant services (Modbus, DNP3, Telnet, FTP, web mgmt)
nmap -T2 --max-rate 50 -Pn -p 21,23,80,443,502,20000 --open \
  -oG "${OUT}.gnmap" "$TARGET" >/dev/null

echo "=== Hosts with exposed SCADAPack-relevant services ==="
grep "Ports:" "${OUT}.gnmap" | awk '{print $2, $3, $4, $5, $6, $7}'

# 2) Flag legacy cleartext management services that should be DISABLED per hardening guidance
echo ""
echo "=== ALERT: Cleartext/legacy management services detected (Telnet/FTP) ==="
grep -E "23/open|21/open" "${OUT}.gnmap" | awk '{print $2}' | sort -u

# 3) Confirm DNP3 (20000) responders for RTU inventory
echo ""
echo "=== DNP3 responders (likely RTU population) ==="
grep "20000/open" "${OUT}.gnmap" | awk '{print $2}' | sort -u

# 4) Check whether any RTU management interface answers from a non-OT test host
#    (run from an IT-side host against the RTU subnet to validate segmentation)
echo ""
echo "=== Segmentation check: run this script from an IT-side host against the OT subnet."
echo "    ANY open port in the output above = segmentation failure. ==="

echo ""
echo "Results saved to ${OUT}.gnmap — reconcile against your authorized RTU inventory."

Remediation

CVE-2026-81861 has no unaffected firmware version — remediation is driven by the vendor mitigations in the Schneider Electric security notification referenced by ICSA-26-258-04, plus compensating controls. Work through this sequence:

1. Retrieve and apply the official mitigations. Download the Schneider Electric security notification linked from CISA ICSA-26-258-04 and the associated CSAF document. Follow the vendor's Secure Lock configuration and hardening instructions exactly for each product variant (47x, 47xi, 47xd, 470R, 57x). Do not assume the Secure Lock feature, as currently configured, is protecting configuration — the advisory exists because it may not be.

2. Inventory every unit. All versions are affected, so every SCADAPack x70 in the field — including spares in storage and units at unmanned sites — must be reconciled against the mitigation. Use the discovery script above plus your asset management records. RTUs at remote wellheads and lift stations are the most commonly forgotten population.

3. Eliminate internet exposure immediately. Verify no SCADAPack management interface, DNP3, or Modbus service is reachable from the public internet. If any are found, treat it as an incident: pull the exposure, review logs for prior unauthorized access, and rotate any credentials or configuration secrets stored on the device.

4. Enforce segmentation and access control. RTU management and industrial-protocol ports (21, 23, 80, 443, 502, 20000) should be reachable only from approved engineering stations and SCADA masters, enforced at firewalls/data diodes between IT and OT zones per IEC 62443 zoning. Deploy the Sigma/KQL detections above as the tripwire verifying your segmentation holds.

5. Disable legacy cleartext services. Where operationally feasible, disable Telnet and FTP on the RTUs and use encrypted management channels. Cleartext services compound this weakness by exposing configuration traffic — and any embedded credentials — to passive interception.

6. Protect configuration data as sensitive. Because the impact is confidentiality of RTU configuration, treat configuration files and backups as classified engineering data: encrypt at rest, restrict to engineering workstations, and monitor for unauthorized copies or transfers.

7. Monitor for follow-on activity. Assume configuration disclosure enables future manipulation. Baseline normal DNP3/Modbus function-code patterns per master station so that WRITE, SAVE_CONFIGURATION, and restart commands outside maintenance windows page an analyst — those detections are your early warning if this weakness is ever leveraged in an intrusion.

8. Subscribe to CISA ICS advisories and Schneider Electric security notifications so the firmware update path — when the vendor publishes one — lands in your patch pipeline immediately rather than at the next annual maintenance cycle.

There is no CISA KEV deadline for this CVE as of publication, but for OT operators under regulatory regimes (TSA pipeline security directives, NERC CIP-adjacent environments, state water-sector rules), document your mitigation timeline now — auditors and regulators will ask.

Key Takeaways

• CVE-2026-81861 affects every version of the SCADAPack 47x, 47xi, 47xd, 470R, and 57x RTUs — there is no safe firmware; vendor mitigations plus compensating controls are the remediation.
• The Secure Lock weakness exposes RTU configuration confidentiality — reconnaissance-grade data that fuels follow-on process manipulation. Do not down-rank it because it isn't a direct control compromise.
• Detection is your mitigation verification. Alerts on non-engineering-station access to management ports and sensitive DNP3 function codes confirm your segmentation is actually working.
• No active exploitation is known today. The window between ICS advisory publication and public PoC development is historically short — use it.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub