CISA published 10 ICS advisories on June 23, 2026, covering vulnerabilities in Siemens WinCC Certificate Manager, Siemens SIPROTEC 5, and Siemens products using OpenSSL, among others. Separately, ICSA-26-167-02 (published June 16) documents an unauthenticated remote code execution vulnerability in Rockwell Automation RSLinx Classic — industrial communication software deployed across tens of thousands of sites globally. This briefing covers the operational risk and remediation guidance for these advisories.
Rockwell Automation RSLinx Classic — Unauthenticated RCE (ICSA-26-167-02)
RSLinx Classic is Rockwell Automation’s OPC and communication server software, used to bridge Logix controllers, legacy PLC-5 and SLC platforms, and enterprise software. It serves as the connectivity layer between HMI software, SCADA systems, and engineering workstations in Rockwell-heavy environments.
The vulnerability: A stack-based buffer overflow in RSLinx Classic’s Ethernet communication handler allows an unauthenticated, network-adjacent attacker to send a malformed packet that overwrites the stack and achieves remote code execution. No authentication is required. The vulnerability resides in a component that listens on UDP port 44818 (the standard EtherNet/IP port) and TCP port 2222 by default.
CVSS: Not yet final in public advisories, but stack buffer overflow with no authentication and network access typically scores 9.8 (Critical).
Affected versions: RSLinx Classic v4.30 and earlier. V4.31.00 contains the fix.
Operational context: RSLinx Classic is found in nearly every Rockwell Automation OT environment as the OPC-DA server for HMI and SCADA connectivity. In many sites, it runs on engineering workstations that have dual-homed network connections — one on the OT network segment and one on the IT/engineering network. Exploitation from the IT network therefore provides direct OT network access to an unauthenticated attacker.
Remediation
Immediate:
-
Update to RSLinx Classic v4.31.00 via Rockwell Automation’s Product Compatibility and Download Center (PCDC).
-
If immediate patching is not possible, implement network ACLs to restrict access to UDP/44818 and TCP/2222 on RSLinx hosts to authorised HMI and engineering workstation IP addresses only:
# Example iptables rule for Linux-based firewall protecting Windows RSLinx host
iptables -A INPUT -p udp --dport 44818 ! -s 10.0.50.0/24 -j DROP
iptables -A INPUT -p tcp --dport 2222 ! -s 10.0.50.0/24 -j DROP- Audit which RSLinx Classic hosts are reachable from IT network segments or from the internet. Any RSLinx host with direct internet reachability should be treated as critically exposed.
Siemens WinCC Certificate Manager (ICSA-26-174-01)
Siemens WinCC is one of the most widely deployed SCADA/HMI platforms globally, used in manufacturing, energy, water treatment, and building automation. The June 23 advisory covers a vulnerability in WinCC’s Certificate Manager component.
The vulnerability: An improper privilege validation in the WinCC Certificate Manager service allows a low-privileged local user to escalate privileges to SYSTEM on the WinCC server. This is a local privilege escalation, not a remote code execution — it requires prior foothold on the WinCC server, but given that WinCC servers often run under domain accounts and are reachable from engineering workstations, lateral movement to WinCC is a common post-initial-access step in OT intrusions.
Affected versions: WinCC V7.x and V8.x prior to patch versions specified in ICSA-26-174-01.
Remediation: Apply the hotfix linked in ICSA-26-174-01. Siemens distributes security patches via the Siemens Industry Online Support (SIOS) portal. Verify the fix by checking the Certificate Manager service runs as a non-SYSTEM account post-patch.
As a compensating control: restrict local user accounts on WinCC servers to the minimum required for operations. WinCC servers should not have general-purpose user accounts — operator access should be via dedicated OT operator accounts with the minimum WinCC runtime permissions.
Siemens SIPROTEC 5 (ICSA-26-174-02)
Siemens SIPROTEC 5 is a protection relay family used in electrical substations, power generation, and transmission grid protection. The June 23 advisory documents a vulnerability affecting the device’s web interface.
The vulnerability: An improper input validation in the SIPROTEC 5 web interface allows an authenticated attacker (requiring valid device credentials) to send a crafted HTTP request that causes the device’s web server process to crash. Repeated exploitation can create a persistent denial-of-service condition against the web management interface, disrupting remote configuration and monitoring capabilities.
Operational impact: A crashed SIPROTEC 5 web interface does not affect protection relay functionality — the relay continues performing its primary power grid protection role. The impact is on remote management and monitoring access. However, loss of web interface access in a critical substation during a concurrent grid event could compound incident response complexity.
Affected firmware: SIPROTEC 5 firmware versions prior to V9.84.
Remediation: Update device firmware to V9.84. Access the firmware update via SIOS. Where immediate firmware update is not operationally feasible, restrict web interface access to the relay to authorised management workstations only via access control lists on the substation LAN.
Context: ICS Advisory Volume Trends
This June advisory batch continues a multi-year trend of increasing ICS vulnerability disclosure volume. 2025 set a record with 2,155 CVEs across 508 CISA ICS advisories — the 2026 pace is tracking above that level. For OT security teams, this creates a patching prioritisation challenge that is different from IT environments:
- OT patches often require production downtime windows, which may only occur quarterly or annually
- Vendor support timelines for OT products may not align with software EOL expectations
- Some older PLC and SCADA platforms receive security patches only as backports, not as version upgrades
The practical implication: maintain a risk-ranked register of unpatched OT vulnerabilities, prioritise based on network exposure and exploitation probability, and use network controls (segmentation, access control lists, protocol inspection at the DMZ) as compensating controls for vulnerabilities that cannot be patched on short notice.