CVE-2026-9637: Rockwell Automation Logix Platform Out-of-Bounds Vulnerability — Detection and Remediation Guide for OT Defenders

CISA has published ICS advisory ICSA-26-244-03, disclosing CVE-2026-9637 — an Improper Restriction of Operations within the Bounds of a Memory Buffer weakness (CVSS v3 7.5, High) affecting the core of Rockwell Automation's Logix control platform: ControlLogix 5580, CompactLogix 5380, GuardLogix 5580, and Compact GuardLogix 5380 controllers. If your organization runs manufacturing, energy, water, pharmaceutical, or any process environment on Allen-Bradley Logix hardware, this advisory applies to you.

Out-of-bounds memory conditions in programmable logic controllers are not abstract IT concerns. A successful exploit against a controller's firmware memory space can crash the CPU (denial of control / denial of view), corrupt the running control application, or — depending on exploit maturity — alter controller behavior. GuardLogix variants are *safety controllers*: they execute safety instrumented functions that keep people and equipment out of harm's way. A 7.5-severity memory safety flaw in that family demands immediate attention from both security and operations leadership.

This post breaks down what is affected, how defenders should think about exposure and detection on OT networks, and the concrete remediation path.

Technical Analysis

Affected Products and Versions

Per the CISA advisory, the following product families and firmware revisions are vulnerable:

Two things stand out for defenders:

1. All firmware through V33 is affected, plus specific point releases of V34, V35, and V36. This is not a legacy-only problem — organizations that patched aggressively to current firmware trains may still be exposed if they landed on an affected point release.
2. Safety controllers are in scope. GuardLogix and Compact GuardLogix run safety logic (SIL-rated functions). Any vulnerability class that can disrupt controller execution on these platforms carries a potential process-safety dimension, not just an availability one.

Vulnerability Class: CWE-119-Style Memory Bounds Violation

CVE-2026-9637 is categorized as Improper Restriction of Operations within the Bounds of a Memory Buffer (CVSS v3 7.5 — consistent with a network-reachable, low-complexity, availability-impacting flaw). On Logix platforms, the attack surface that matters operationally is the controller's handling of network-facing services — principally EtherNet/IP (CIP) communications on TCP/UDP 44818 and CIP encapsulation on UDP 2222, as well as web/diagnostic interfaces where enabled.

From a defender's perspective, the realistic exploitation model for this class of bug on a PLC is:

• Delivery vector: Malformed or specially crafted protocol traffic sent to the controller over reachable industrial protocol ports. Attackers do not need credentials if they can reach the controller's CIP stack — which is why Purdue Level 2/3 segmentation and conduits are the primary compensating control.
• Impact: Memory access outside intended bounds typically manifests as a major non-recoverable fault (MNRF) on Logix controllers — the CPU faults, the control application halts, outputs transition to their configured fault state, and recovery requires a manual key-switch or power cycle and program reload. In a running plant, that is a production-stopping (and potentially safety-relevant) event.
• Prerequisites: Network reachability to the controller. No authentication is implied by a 7.5 score with no privileges required. The entire defense hinges on who can talk to the PLC.

Exploitation Status

At the time of publication of ICSA-26-244-03, there is no confirmed public proof-of-concept exploit and no report of active in-the-wild exploitation attributed to this CVE. The advisory has not been cited as added to the CISA Known Exploited Vulnerabilities (KEV) catalog. That said, defenders should treat this as a when, not if scenario: Rockwell Logix is one of the most studied PLC families in both academic and adversary research communities, memory-corruption primitives in CIP stacks have historically been weaponized for denial-of-control attacks, and ICS-focused threat actors routinely operationalize CISA ICS advisories within weeks of disclosure. Patch and segment now — do not wait for a PoC to appear on a research blog.

Detection & Response

Because PLCs do not run EDR agents, detection for CVE-2026-9637 exploitation attempts lives in two places: (1) network-level monitoring of industrial protocol traffic, and (2) Windows-side telemetry from engineering workstations and any host communicating with the control zone. The detection strategy below focuses on the highest-fidelity signals: unexpected EtherNet/IP conversations with controllers, connection storms consistent with fuzzing/exploit delivery, and post-impact indicators.

Sigma Rules

These rules target network connection telemetry (from Zeek, firewalls exporting to your SIEM via Sysmon-style network connection events, or OT network monitoring sensors). Tune the allowlist logic to your documented engineering workstations and HMIs before enabling at high fidelity.

---
title: EtherNet/IP Connection to Logix Controller from Non-Engineering Host
id: 3f9a1c74-2b6d-4e18-9c52-7a4d8e1f0b23
status: experimental
description: Detects TCP connections to EtherNet/IP (CIP) port 44818 on OT assets from hosts not on the approved engineering workstation/HMI allowlist. Exploitation of CVE-2026-9637 requires network reachability to the controller CIP stack; unauthorized sources are a high-fidelity signal.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-244-03
  - https://attack.mitre.org/techniques/T0886/
author: Security Arsenal
date: 2026/03/10
tags:
  - attack.lateral_movement
  - attack.t0886
  - ics.ot
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort: 44818
  filter_authorized_sources:
    SourceIp:
      - '10.10.20.0/24' # Replace: engineering workstation VLAN
      - '10.10.30.0/24' # Replace: HMI/SCADA VLAN
  condition: selection and not filter_authorized_sources
falsepositives:
  - Newly deployed historian or MES connectors not yet added to the allowlist
  - Asset inventory/vulnerability scanners authorized for OT (schedule and allowlist scanner IPs)
level: high
---
title: EtherNet/IP Connection Storm to OT Controller (Potential Fuzzing or Exploit Delivery)
id: 8b2e5d91-4c7a-4f30-a61d-9e0f2b5c7d84
status: experimental
description: Detects an abnormally high rate of connection attempts to EtherNet/IP port 44818 or CIP encapsulation port 2222 directed at a single OT destination. Memory-corruption exploit delivery and protocol fuzzing against PLCs typically generate short-lived, high-volume session patterns distinct from steady-state HMI polling.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-244-03
  - https://attack.mitre.org/techniques/T0846/
author: Security Arsenal
date: 2026/03/10
tags:
  - attack.impact
  - attack.t0846
  - ics.ot
logsource:
  category: network_connection
detection:
  selection:
    DestinationPort:
      - 44818
      - 2222
  condition: selection | count(DestinationIp) by SourceIp > 50
  timeframe: 60s
falsepositives:
  - Controller download/firmware update operations from Studio 5000 (suppress during approved maintenance windows)
  - Misconfigured HMI with aggressive reconnect logic
level: medium

KQL — Microsoft Sentinel / Defender

This hunt assumes your OT perimeter firewalls, OT network monitoring sensors (e.g., via CEF/Syslog forwarding), or Defender for IoT are ingesting network flow data into Sentinel. It surfaces unauthorized talkers to Logix controllers and connection-volume anomalies consistent with exploit attempts against CVE-2026-9637.

// Hunt 1: Unauthorized sources communicating with controllers over EtherNet/IP
// Replace the allowlist ranges with your documented engineering workstation / HMI subnets.
let AuthorizedOTalkers = dynamic(["10.10.20.0/24", "10.10.30.0/24"]);
let OTControllerSubnet = "10.30.";  // Replace: prefix of your control-zone PLC subnet
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationPort in (44818, 2222)
| where DestinationIP startswith OTControllerSubnet
| where not(ipv4_is_in_range(SourceIP, AuthorizedOTalkers[0])
         or ipv4_is_in_range(SourceIP, AuthorizedOTalkers[1]))
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceIP, DestinationIP, DestinationPort, DeviceAction
| order by ConnectionCount desc;

// Hunt 2: Connection-volume anomaly against a single controller (fuzzing/exploit delivery pattern)
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationPort == 44818
| summarize Hits = count() by SourceIP, DestinationIP, bin(TimeGenerated, 5m)
| where Hits > 100   // Tune to baseline: steady-state HMI polling is typically far lower per 5 min
| order by Hits desc;

// Hunt 3 (Defender for Endpoint): Any endpoint initiating EtherNet/IP sessions outside the allowlist
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort == 44818
| extend RemoteIPCidr = strcat(extract(@"^(\d+\.\d+\.\d+)\.", 1, RemoteIP), ".0/24")
| where RemoteIP startswith "10.30."  // control-zone PLC subnet
| summarize FirstSeen = min(TimeGenerated), Connections = count()
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP
| where InitiatingProcessFileName !in~ ("rslinx.exe", "studio5000.exe", "rslogix5000.exe", "factorytalklinxgw.exe")  // known-good Rockwell software
| order by Connections desc;

Velociraptor VQL — Engineering Workstation Hunt

Engineering workstations are the most likely pivot point into the control zone. This artifact hunts for processes holding live EtherNet/IP sessions to controllers that are not signed Rockwell/FactoryTalk software — a strong indicator of attacker tooling staged on an EWS.

-- Hunt for non-Rockwell processes holding EtherNet/IP (44818) sessions on Windows hosts
-- Deploy against engineering workstations and any host with control-zone reachability.
LET known_rockwell = ('rslinx', 'studio5000', 'rslogix', 'factorytalk', 'rsemulate', 'logixdesigner')

SELECT Pid,
       Name,
       Exe,
       Username,
       CommandLine,
       Laddr.IP AS LocalAddress,
       Raddr.IP AS RemoteAddress,
       Raddr.Port AS RemotePort,
       Status
FROM netstat()
WHERE (Raddr.Port = 44818 OR Raddr.Port = 2222)
  AND NOT (Exe =~ '(?i)rockwell|allen.?bradley'
           OR Name =~ '(?i)' + join(sep='|', array=known_rockwell))

Asset Inventory Script — Identify Vulnerable Logix Firmware in Your Environment

You cannot patch what you have not inventoried. The script below performs a defensive, read-only sweep of your control-zone subnet for EtherNet/IP listeners and pulls identity objects where accessible, producing a CSV for firmware-version reconciliation against the affected list. Run only during an approved change window and only against subnets you are authorized to scan. Passive discovery (mirrored SPAN traffic, existing OT monitoring) is always preferred over active scanning on sensitive process networks.

#Requires -Version 5.1
# Logix EtherNet/IP Discovery & Firmware Reconciliation (Defensive, Read-Only)
# Run from an authorized engineering workstation during an approved maintenance window.

$Subnets      = @("10.30.10", "10.30.11")          # Control-zone subnets to sweep
$Port         = 44818                               # EtherNet/IP TCP
$TimeoutMs    = 400
$OutputCsv    = ".\Logix_Inventory_$(Get-Date -Format yyyyMMdd_HHmm).csv"

# Affected version patterns per ICSA-26-244-03
$AffectedPattern = '^(V(1?[0-9]|2[0-9]|3[0-3])(\.|$))|(V34\.01[1-4]$)|(V35\.01[1-3]$)|(V36\.01[12]$)'

$Results = foreach ($subnet in $Subnets) {
    1..254 | ForEach-Object -Parallel {
        $ip = "$using:subnet.$_"
        $client = New-Object System.Net.Sockets.TcpClient
        try {
            $async = $client.BeginConnect($ip, $using:Port, $null, $null)
            if ($async.AsyncWaitHandle.WaitOne($using:TimeoutMs) -and $client.Connected) {
                # Host is listening on 44818 — record it. Full identity object
                # retrieval (CIP List Identity, service 0x63) should be performed
                # via authorized OT tooling; we flag the live listener here.
                [PSCustomObject]@{
                    IPAddress     = $ip
                    Port44818Open = $true
                    DiscoveredAt  = (Get-Date)
                    Notes         = "EtherNet/IP listener — verify model & firmware via RSLinx/Studio 5000"
                }
            }
        } catch { } finally { $client.Close() }
    } -ThrottleLimit 64
}

$Results | Where-Object { $_ } | Export-Csv -Path $OutputCsv -NoTypeInformation
Write-Host "[+] Discovery complete. $($Results.Count) EtherNet/IP listeners found. Output: $OutputCsv"
Write-Host "[!] NEXT STEP: Reconcile each host's firmware against affected ranges:"
Write-Host "    <=V33, V34.011-V34.014, V35.011-V35.013, V36.011-V36.012 (all four Logix families)"

# After recording firmware versions (from Studio 5000 / controller web page) into a
# column named 'FirmwareVersion', flag affected units:
#   Import-Csv $OutputCsv | Where-Object { $_.FirmwareVersion -match $AffectedPattern }

Remediation

1. Inventory and Version Reconciliation (Immediate — this week)

Build or validate your Logix asset inventory. For every ControlLogix 5580, CompactLogix 5380, GuardLogix 5580, and Compact GuardLogix 5380 in service, record the exact firmware revision. Flag anything matching:

• ≤V33 (all revisions)
• V34.011 through V34.014
• V35.011 through V35.013
• V36.011 through V36.012

If you lack an inventory, use the script above as a starting point and validate results against Studio 5000 / FactoryTalk records. This step is non-negotiable — the affected version ranges are non-contiguous, so "we're on V35" tells you nothing without the point release.

2. Apply Vendor-Corrected Firmware (Priority: Safety Controllers First)

Follow the remediation guidance in the official advisories:

• CISA ICSA-26-244-03: https://www.cisa.gov/news-events/ics-advisories/icsa-26-244-03
• Rockwell Automation security advisory / CSAF document: linked from the CISA advisory ("View CSAF") — Rockwell publishes machine-readable CSAF with fixed-version mappings per product family.

Operational sequencing guidance from experience:

1. GuardLogix / Compact GuardLogix first. Safety controllers carry the highest consequence. Coordinate with your functional safety team — firmware updates on safety systems require revalidation of safety functions and may require re-signature of the safety task.
2. ControlLogix / CompactLogix process controllers second, scheduled into planned outages.
3. Test firmware on a non-production controller or emulator (Studio 5000 Logix Emulate) before touching production. Validate your application, add-on instructions, and communications (produced/consumed tags, MSG instructions, HMI connections) against the target firmware.
4. Capture and verify controller images before and after: export the ACD/L5X, record controller properties, and verify program signature/checksum post-upgrade.

3. Compensating Controls (Do These Regardless of Patch Timeline)

Patching PLC firmware takes outage windows many plants won't get for months. These controls reduce exploitability today:

• Segment and conduits: Enforce Purdue Level 2/3 boundaries. Only engineering workstations, HMIs, historians, and approved jump hosts should be able to reach controller CIP ports (TCP/UDP 44818, UDP 2222). Everything else gets a deny rule. This is the single most effective mitigation for a network-reachable PLC memory bug.
• Controller keyswitch hardening: Where operational mode permits, run controllers in RUN mode (not REMote RUN) so remote mode changes and program modifications require physical access. Evaluate CIP Security and FactoryTalk Security policy enforcement on supported firmware.
• Disable unneeded services: Turn off the controller's embedded web server if not operationally required; disable unused Ethernet ports on 5380 dual-port models where feasible.
• Network monitoring: Deploy the Sigma/KQL detections above. At minimum, alert on any new source IP talking EtherNet/IP to the control zone.
• Change management: Enforce approval workflows for any Studio 5000 online session, download, or firmware flash — and log them centrally.

4. Detection Validation

Before closing this out, test your detections: from a test host (with authorization), generate EtherNet/IP session traffic to a lab controller and confirm the unauthorized-talker alert fires end-to-end — sensor, SIEM, analyst queue. A detection that has never been exercised is a hope, not a control.

5. Reporting and Governance

• Track remediation under your vulnerability management program with CVE-2026-9637 / ICSA-26-244-03 as the tracking key. CISA ICS advisories carry an implicit urgency for critical infrastructure operators; document your patch timeline and compensating controls for audit (NIST CSF, IEC 62443, and sector regulations all expect traceable OT vulnerability handling).
• Brief operations and safety leadership on the GuardLogix exposure specifically — safety-system availability decisions belong at the plant-manager level, not just in the SOC.

Bottom Line

CVE-2026-9637 is a high-severity memory-bounds flaw in the most widely deployed PLC family in North American industry, and it includes safety controllers in its blast radius. There is no public exploit today — which means defenders have a window. Use it: inventory every Logix CPU, lock down who can speak EtherNet/IP to your control zone, get network detections live, and drive firmware remediation through your change process with safety controllers at the front of the line. In OT, the organizations that fare best against advisories like ICSA-26-244-03 are the ones that already know exactly what they own and exactly who is allowed to talk to it.

Related Resources

Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub