CISA has published ICSA-26-244-01, disclosing four vulnerabilities in Rockwell Automation's RSLinx Classic — the communications gateway that sits between Windows-based HMI, historian, and engineering workstations and the Allen-Bradley control network. All versions RSLinx Classic 4.50 and earlier are affected:
- CVE-2026-9621
- CVE-2026-9622
- CVE-2026-9624
- CVE-2026-9625
The underlying weaknesses are classic memory-safety defects: Integer Overflow or Wraparound (CWE-190), Integer Underflow (CWE-191), and Buffer Copy without Checking Size of Input (CWE-120, classic buffer overflow). The advisory carries a CVSS v3 score of 8.6 (High). Successful exploitation allows an attacker to cause a denial-of-service condition on the affected product.
If you run an Allen-Bradley environment, RSLinx Classic is almost certainly installed somewhere on your operations network — on HMI servers, engineering workstations, and OPC data-collection nodes. A DoS against RSLinx does not brick a PLC, but it severs the visibility and data path between operators and the control layer. In a critical manufacturing environment, that means loss of view, loss of historization, and — depending on how your HMI redundancy is architected — loss of control from the supervisory layer. Treat this as a priority remediation item for your next maintenance window.
Technical Analysis
Affected Products and Versions
| Product | Affected Versions | CVEs |
|---|---|---|
| Rockwell Automation RSLinx Classic | <= 4.50 | CVE-2026-9621, CVE-2026-9622, CVE-2026-9624, CVE-2026-9625 |
Deployment profile: Critical Manufacturing sector, deployed worldwide. Rockwell Automation is headquartered in the United States.
How the Vulnerabilities Work — Defender's View
RSLinx Classic is a Windows service/application that brokers industrial protocol traffic — most prominently EtherNet/IP (TCP/UDP 44818) and legacy CIP over serial/DF1 — and exposes that data to client applications via OPC (DA/AE) and DDE. It parses inbound protocol frames from the control network and from any host able to reach it.
The disclosed defects are parsing-time memory corruption issues:
- Integer overflow/underflow (CVE-2026-9621, CVE-2026-9622, and related): A length or size field supplied in a crafted protocol message wraps during arithmetic, causing the parser to miscalculate a buffer boundary. Integer underflow is particularly dangerous here — a value of
-1treated as unsigned becomes an enormous allocation or copy size. - Classic buffer overflow (CVE-2026-9624/9625 family): A buffer copy performed without validating input size against the destination buffer. In a protocol parser, this is typically triggered by an oversized or malformed field in an EtherNet/IP or CIP message.
The stated impact in the advisory is denial of service — the malformed input crashes or hangs the RSLinx service. That is the confirmed impact. However, any practitioner reading a CWE-120 in a network-facing parser should assume the code-execution question is open until the vendor states otherwise. Memory-safety bugs in C/C++ protocol parsers have a long history of being upgraded from "DoS" to "RCE" once researchers spend time with them.
Exploitation Requirements and Status
- Exploitation vector: Network. An attacker must be able to send traffic to a host running RSLinx Classic — typically via EtherNet/IP on TCP/44818 or via the service's OPC/RPC interfaces. No authentication to the protocol parser is required for pre-parse crashes.
- In-the-wild exploitation: As of publication, no confirmed active exploitation has been reported in the advisory. These are vulnerability disclosures, not a known-exploited campaign.
- CISA KEV: Not currently listed. Monitor the CISA KEV catalog — ICS parser bugs with CVSS 8.6 have historically moved quickly once PoCs circulate.
Why This Hurts More Than a Typical Windows DoS
RSLinx is often the single communications path between Level 3/4 (operations, historians, MES) and Level 2 (supervisory control). A crash of the RSLinx service produces:
- Loss of view — HMI tags freeze, operators go blind.
- Broken data collection — historians and MES lose their OPC feed, creating data gaps that complicate both operations and any subsequent forensic investigation.
- Cascade effects — client applications that block on OPC calls may hang, and automatic service recovery on a repeat-crash loop can spam Windows event logs and destabilize the host.
In a ransomware-adjacent scenario, deliberately crashing RSLinx across an operations segment is a cheap way to blind defenders before a second-stage action against the control layer. That is why detection matters even when the impact is "only" DoS.
Detection & Response
The observable behaviors worth hunting are: (1) crash or unexpected restart of the RSLinx process/service, (2) EtherNet/IP connections to RSLinx hosts from unexpected sources — especially IT-side or internet-adjacent hosts, and (3) abnormal connection volume to TCP/44818 consistent with fuzzing or malformed-packet probing.
SIGMA Rules
---
title: RSLinx Classic Process Crash or Unexpected Termination
id: 3c7a91e2-4f56-4b8d-9a21-7e6c5d0b2f44
status: experimental
description: Detects crash, unexpected exit, or rapid respawn of the Rockwell RSLinx Classic process, consistent with denial-of-service exploitation of CVE-2026-9621/9622/9624/9625 memory-corruption flaws.
references:
- https://www.cisa.gov/news-events/ics-advisories/icsa-26-244-01
author: Security Arsenal
date: 2026/02/14
tags:
- attack.impact
- attack.t1499
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith:
- '\RSLINX.exe'
- '\RSLINXNG.exe'
CommandLine|contains:
- '-service'
- '/service'
filter_known_paths:
Image|startswith:
- 'C:\Program Files (x86)\Rockwell Software\RSLinx\'
- 'C:\Program Files\Rockwell Software\RSLinx\'
condition: selection and not filter_known_paths
falsepositives:
- Legitimate RSLinx restarts during maintenance windows (tune with change records)
level: high
---
title: EtherNet/IP Connection to RSLinx Host from Non-OT Source
id: 9b2e4d17-8c3a-4f65-b7d2-1a8e6c4f9035
status: experimental
description: Detects network connections to TCP/44818 (EtherNet/IP) on hosts running RSLinx Classic originating from processes or hosts outside expected engineering/HMI patterns, consistent with remote probing of CVE-2026-9621/9622/9624/9625.
references:
- https://www.cisa.gov/news-events/ics-advisories/icsa-26-244-01
author: Security Arsenal
date: 2026/02/14
tags:
- attack.discovery
- attack.t1046
logsource:
category: network_connection
product: windows
detection:
selection:
DestinationPort: 44818
Initiated: 'true'
filter_approved_clients:
Image|endswith:
- '\RSLINX.exe'
- '\FactoryTalkViewSE.exe'
- '\Studio5000.exe'
- '\RSLogix5000.exe'
condition: selection and not filter_approved_clients
falsepositives:
- Third-party OPC gateways and historians not in the filter list — build an approved-client baseline per host
level: medium
The first rule catches the payload of the attack — the crash/respawn of RSLinx itself, including execution from a non-standard path. The second rule is your segmentation tripwire: on a properly segmented OT network, almost nothing should be initiating 44818 sessions to an RSLinx host except known HMI, historian, and engineering tools. Tune the approved-client filter against your actual environment before deploying to production, or it will be disabled within a week.
KQL — Microsoft Sentinel / Defender
RSLinx hosts are Windows machines, so Defender for Endpoint telemetry plus network connection data gives you solid coverage. If you ingest OT firewall logs via CEF/Syslog, the second query covers east-west traffic.
// Hunt 1: RSLinx process crashes, restarts, and crash artifacts (WerFault, WER reports)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName in~ ("RSLINX.exe", "RSLINXNG.exe", "WerFault.exe", "WerFaultSecure.exe")
or ProcessCommandLine has_any ("RSLINX", "RSLinx")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, FolderPath, InitiatingProcessFileName, AccountName
| order by TimeGenerated desc
;
// Hunt 2: Inbound EtherNet/IP (44818) connections to RSLinx hosts from non-standard sources
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort == 44818 or LocalPort == 44818
| where ActionType == "InboundConnectionAccepted"
| summarize ConnectionCount = count(), DistinctSources = dcount(RemoteIP), SourceIPs = make_set(RemoteIP, 20)
by DeviceName, LocalIP, bin(TimeGenerated, 1h)
| where DistinctSources > 3 or ConnectionCount > 500
| order by ConnectionCount desc
;
// Hunt 3: OT firewall / switch syslog — connection floods to RSLinx hosts on 44818 (CEF ingestion)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationPort == 44818
| summarize Hits = count(), Sources = make_set(SourceIP, 25) by DestinationIP, bin(TimeGenerated, 1h)
| where Hits > 1000
| order by Hits desc
The volume thresholds in Hunts 2 and 3 are starting points — baseline your normal EtherNet/IP polling rates first. Scanner-driven fuzzing of a protocol parser produces connection churn an order of magnitude above legitimate OPC polling, but every plant's normal is different.
Velociraptor VQL
Use this artifact to sweep your engineering workstation and HMI fleet for RSLinx version exposure and live EtherNet/IP listeners — it doubles as both an exposure inventory and a hunt for the service listening where it should not be.
-- RSLinx Classic exposure and live listener hunt (CVE-2026-9621/9622/9624/9625)
-- Identifies running RSLinx processes, their binary version, and active 44818 listeners
LET procs = SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)rslinx'
LET listeners = SELECT Pid, Name, Laddr, Raddr, Status
FROM netstat()
WHERE Laddr.Port =~ '44818'
OR Name =~ '(?i)rslinx'
SELECT * FROM procs
UNION ALL
SELECT Pid, Name, Laddr.IP AS Exe, Laddr.Port + ' -> ' + Raddr.IP + ':' + Raddr.Port AS CommandLine, Status AS Username, '' AS CreateTime
FROM listeners
For a clean version inventory at scale, pair that with a file-version pull against the binary:
-- Pull RSLinx binary version across the fleet for <= 4.50 exposure check
SELECT FullPath, version_info(filename=FullPath) AS VersionInfo, Size, Mtime
FROM glob(globs=[
'C:/Program Files (x86)/Rockwell Software/RSLinx/RSLINX.exe',
'C:/Program Files/Rockwell Software/RSLinx/RSLINX.exe'
])
Remediation and Verification Script
Use this PowerShell script on HMI and engineering workstations to enumerate installed RSLinx versions, identify the 44818 listener, and apply a compensating host-firewall restriction while patching is scheduled.
# RSLinx Classic exposure check + compensating controls for ICSA-26-244-01
# Run elevated. Test in one cell/area before fleet deployment.
# 1. Enumerate installed RSLinx Classic versions
$paths = @(
"$env:ProgramFiles (x86)\Rockwell Software\RSLinx\RSLINX.exe",
"$env:ProgramFiles\Rockwell Software\RSLinx\RSLINX.exe"
)
foreach ($p in $paths) {
if (Test-Path $p) {
$v = (Get-Item $p).VersionInfo.ProductVersion
Write-Host "[FOUND] $p -- Version: $v"
if ([version]($v -replace '[^0-9.]','') -le [version]'4.50.0.0') {
Write-Host "[VULNERABLE] Version <= 4.50 — subject to CVE-2026-9621/9622/9624/9625" -ForegroundColor Red
}
}
}
# 2. Show who is listening on EtherNet/IP
Get-NetTCPConnection -LocalPort 44818 -State Listen -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess,
@{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}} | Format-Table -AutoSize
# 3. Compensating control: restrict inbound 44818 to approved OT peers only
# Replace the -RemoteAddress list with YOUR HMI/historian/engineering subnet(s)
$approvedPeers = @('10.10.20.0/24','10.10.30.0/24') # <-- EDIT for your environment
New-NetFirewallRule -DisplayName 'ICS - Restrict EtherNet-IP to OT Peers (ICSA-26-244-01)' `
-Direction Inbound -Protocol TCP -LocalPort 44818 `
-RemoteAddress $approvedPeers -Action Allow -Profile Any
New-NetFirewallRule -DisplayName 'ICS - Block EtherNet-IP All Others (ICSA-26-244-01)' `
-Direction Inbound -Protocol TCP -LocalPort 44818 -Action Block -Profile Any
# 4. Enable crash telemetry for RSLinx so DoS attempts are visible in Event Log
New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\RSLINX.exe' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\RSLINX.exe' `
-Name DumpFolder -PropertyType String -Value 'C:\CrashDumps' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\RSLINX.exe' `
-Name DumpCount -PropertyType DWord -Value 5 -Force | Out-Null
Write-Host 'WER local dump collection enabled for RSLINX.exe (C:\CrashDumps)'
Caution on step 3: EtherNet/IP is not a chatty protocol you can firewall casually — legitimate HMI/PLC sessions must be in the approved list or you will blind your operators. Build the peer list from your netstat/VQL baseline first, deploy in audit mode (log-only block rule) for 48–72 hours, then enforce.
Remediation
- Patch to the fixed release. Rockwell Automation's remediation for ICSA-26-244-01 is to update RSLinx Classic beyond version 4.50. Obtain the corrected version through the Rockwell Automation product download portal and validate it against the vendor advisory. Schedule deployment within your next OT maintenance window — do not attempt hot patching of production HMI hosts without change control.
- Inventory first. Most organizations do not know everywhere RSLinx Classic is installed. Use the VQL/PowerShell inventory above across engineering workstations, HMI servers, historian connectors, and jump boxes. Any copy <= 4.50 is in scope.
- Restrict network reachability. RSLinx should never be reachable from IT networks, guest VLANs, or the internet. Enforce deny-by-default on TCP/UDP 44818 at the Level 3.5 / industrial DMZ boundary, and restrict host-level access to approved HMI, historian, and engineering peers only (script above).
- Segment EtherNet/IP east-west. Even within the OT zone, PLC-to-PLC and workstation-to-workstation EtherNet/IP reachability should follow a conduit model per IEC 62443. The buffer-overflow class of these bugs means any host that can reach the parser can crash it — minimize the blast radius.
- Monitor for crash/respawn behavior. Deploy the Sigma and KQL detections above. A repeat-crash loop on RSLINX.exe is your highest-fidelity indicator that someone is exercising these flaws.
- Watch the KEV and follow-up advisories. CWE-120 parser bugs frequently get re-rated. Track the Rockwell Automation security advisories page and CISA's ICS advisories feed for updated impact statements or exploitation reporting.
- Plan for the eventual end-of-life question. RSLinx Classic is a legacy communications platform; Rockwell has been steering customers toward FactoryTalk Linx for years. If your architecture still depends on Classic OPC/DDE paths, use this advisory as the forcing function to evaluate migration — compensating controls are a bridge, not a destination.
Related Resources
Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.