CVE-2025-10478: Rockwell Automation 1756-ENBT EtherNet/IP Module DoS — Detection and Mitigation Guide

CISA has published ICS Advisory ICSA-26-246-05 covering CVE-2025-10478, a remotely exploitable denial-of-service vulnerability in the Rockwell Automation 1756-ENBT ControlLogix EtherNet/IP bridge module. Every version of the module is affected — there is no 'safe' firmware to roll back to. Successful exploitation crashes the module outright, and the only recovery path is a manual restart of the device. For plants running ControlLogix architectures, that means an abrupt loss of EtherNet/IP communications between controllers, I/O, HMIs, and engineering workstations until someone physically intervenes.

The advisory carries a CVSS v3 base score of 7.5 (High) and maps to CWE-754, Improper Check for Unusual or Exceptional Conditions. The affected hardware is deployed worldwide across Critical Manufacturing, Food and Agriculture, Transportation Systems, and Water and Wastewater — sectors where an unexpected communications outage on the control network translates directly into lost production, safety system degradation, or regulatory exposure. Defenders running Rockwell environments should treat this as a priority item for network-level mitigation even in the absence of a confirmed exploit campaign.

Technical Analysis

Affected Products

• Product: Rockwell Automation 1756-ENBT ControlLogix EtherNet/IP Bridge Module
• Affected versions: All versions (vers:all/*)
• CVE: CVE-2025-10478
• CVSS v3: 7.5 (High) — consistent with a network-exploitable, low-complexity, no-authentication, availability-only impact vector (AV:N/AC:L/PR:N/UI:N/A:H pattern)
• CWE: CWE-754 — Improper Check for Unusual or Exceptional Conditions
• Vendor: Rockwell Automation (US-headquartered)
• Advisory: CISA ICSA-26-246-05

How the Vulnerability Works

CWE-754 tells the story: the 1756-ENBT firmware fails to properly validate or handle an unusual or exceptional condition in incoming traffic. In practical terms for this class of EtherNet/IP device, that almost always means a malformed, unexpected, or abnormally sequenced CIP (Common Industrial Protocol) message — or a flood of such messages — directed at the module's EtherNet/IP listener on TCP/UDP port 44818 (the registered EtherNet/IP encapsulation port) causes the firmware to enter an unhandled state and crash.

Key exploitation characteristics from a defender's standpoint:

• No authentication required. EtherNet/IP encapsulation sessions on 44818 are unauthenticated by design in this generation of hardware. Anything that can route to the module can reach the vulnerable code path.
• No user interaction. This is a pure network-triggered condition.
• Availability impact only, but severe. The crash is not a soft fault — the module stops passing traffic until restarted. In a ControlLogix chassis, the ENBT is often the sole communications bridge; its loss severs SCADA visibility, engineering access, and inter-controller messaging simultaneously.
• Recovery requires manual restart. This is the operational killer. There is no watchdog auto-recovery; someone must power-cycle or reset the module, which in 24/7 process environments means the outage window is measured in minutes-to-hours depending on staffing.

Exploitation Status

At the time of the advisory's publication, there is no confirmed in-the-wild exploitation, no public proof-of-concept exploit has been cited by CISA, and CVE-2025-10478 has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. The disclosure arrived through coordinated vulnerability handling, which buys defenders a window to mitigate before weaponization. Do not confuse the absence of active exploitation with the absence of risk: EtherNet/IP DoS conditions are among the lowest-skill attacks in the ICS space — scanners like Shodan routinely index exposed 1756-ENBT modules on the public internet, and trivially crafted CIP traffic against port 44818 has a long history of crashing fragile OT firmware.

Attack Surface Reality Check

The 1756-ENBT is a legacy but ubiquitous module. In most environments we assess, these devices sit on flat Level 2/3 OT networks reachable from the business LAN, from engineering workstations that also browse the internet, and occasionally — due to misconfigured NAT or vendor remote-access arrangements — directly from the internet. A CVSS 7.5 network DoS on a device with no auth, all versions affected, and manual recovery is a segmentation problem as much as a patching problem.

Detection & Response

Because the vulnerable component is embedded firmware on an OT module, traditional endpoint telemetry does not exist on the device itself. Detection must come from network-level monitoring of EtherNet/IP traffic: anomalous volumes or patterns of CIP encapsulation traffic to port 44818, connection attempts from assets that have no legitimate reason to speak EtherNet/IP, and module availability events (the crash itself is a high-fidelity signal). The detections below assume your ICS firewall, OT IDS (Claroty, Nozomi, Dragos, Zeek/Suricata, or similar), or switch SPAN feeds are ingested into your SIEM.

SIGMA Rules

---
title: Anomalous EtherNet/IP Connection Volume to OT Module
type: log_source
description: >
  Detects a high rate of EtherNet/IP encapsulation connections (TCP/UDP 44818)
  from a single source to OT devices. Consistent with scanning, fuzzing, or
  DoS traffic targeting EtherNet/IP modules such as the Rockwell 1756-ENBT
  (CVE-2025-10478).
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-246-05
  - https://attack.mitre.org/techniques/T0814/
author: Security Arsenal
date: 2026/01/15
status: experimental
id: 8c2f4e61-3b7a-4d95-9e12-6f0a2c5b8d47
logsource:
  category: firewall
  product: cisco
detection:
  selection:
    dst_port: 44818
  condition: selection
falsepositives:
  - Legitimate HMI/SCADA polling cycles
  - Engineering workstation downloads/uploads to controllers
level: medium
---
title: EtherNet/IP Traffic from Non-Engineering Asset
type: log_source
description: >
  Detects EtherNet/IP (44818) connections originating from sources outside
  the expected engineering workstation / HMI / SCADA allowlist. The 1756-ENBT
  requires no authentication (CVE-2025-10478), so any reachable host can
  trigger the vulnerable code path. Tune the filter to your known OT clients.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-246-05
  - https://attack.mitre.org/techniques/T0846/
author: Security Arsenal
date: 2026/01/15
status: experimental
id: 3d9a7b22-8c4e-4f61-a5d3-1b9e6c2f7a08
logsource:
  category: netflow
detection:
  selection:
    DestinationPort: 44818
  filter:
    SourceIp|cidr:
      - '10.10.20.0/24' # TODO: replace with your engineering/SCADA VLAN
  condition: selection and not filter
falsepositives:
  - Newly deployed HMI or historian not yet in the allowlist
  - Vendor remote support sessions that bypass jump hosts
level: high
---
title: OT Module Unreachable After EtherNet/IP Traffic Burst
type: log_source
description: >
  Detects ICMP echo-request failures or device-down events targeting known
  OT modules following a burst of 44818 traffic. A crashed 1756-ENBT
  (CVE-2025-10478) stops responding and requires manual restart, making
  availability loss the highest-fidelity post-exploitation signal.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-246-05
  - https://attack.mitre.org/techniques/T0814/
author: Security Arsenal
date: 2026/01/15
status: experimental
id: 61f0c94d-2e8b-4a37-bc51-9d4e7a1f6c93
logsource:
  category: netflow
detection:
  selection:
    DestinationPort: 44818
  timeframe: 5m
  condition: selection | count(SourceIp) by DestinationIp > 500
falsepositives:
  - Firmware download operations to the module
  - Aggressive legitimate polling from misconfigured historians
level: high

Analyst note: The count-based rule above requires a Sigma backend that supports aggregation (e.g., pySigma conversion to Splunk/Sentinel with thresholding). If your pipeline does not, implement the threshold natively in your SIEM correlation layer.

KQL — Microsoft Sentinel / Defender

This query assumes your OT firewall or ICS IDS exports to Sentinel via CommonSecurityLog (CEF) or Syslog. It hunts for two things in one pass: (1) concentrated connection bursts to port 44818 from a single source, and (2) 44818 connections from sources that have never historically spoken EtherNet/IP — both consistent with probing or DoS activity against the 1756-ENBT.

// EtherNet/IP (44818) anomaly hunt — CVE-2025-10478 / ICSA-26-246-05
// Ingest: OT firewall CEF, Claroty/Nozomi/Dragos, or Zeek conn logs via Syslog
let lookback = 7d;
let baseline = 30d;
let enip_traffic =
    CommonSecurityLog
    | where TimeGenerated > ago(baseline)
    | where DestinationPort == 44818
    | summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
                ConnCount=count(), Destinations=dcount(DestinationIP)
        by SourceIP, DeviceVendor, DeviceProduct;
let recent_burst =
    CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where DestinationPort == 44818
    | summarize BurstConnCount=count(), TargetModules=make_set(DestinationIP, 20)
        by SourceIP, bin(TimeGenerated, 1h)
    | where BurstConnCount > 500   // tune to your polling baseline
    | summarize by SourceIP, BurstConnCount, TargetModules;
recent_burst
| join kind=leftouter (enip_traffic) on SourceIP
| project SourceIP, BurstConnCount, TargetModules,
          HistoricalConnCount=ConnCount, HistoricallySeenDestinations=Destinations
| extend SuspiciousNovel = (HistoricalConnCount < 50 or isempty(HistoricalConnCount))
| sort by SuspiciousNovel desc, BurstConnCount desc;

A novel source with high connection volume (SuspiciousNovel == true) should page. A known HMI with a modest bump is likely noise — tune the 500 threshold against your historian polling cadence before enabling alerting.

Velociraptor VQL — Engineering Workstation Hunt

The ENBT module itself cannot run an agent, but your engineering workstations can. Since any host that can route to the module can crash it, hunt for non-standard processes holding EtherNet/IP connections — a quick way to find rogue tooling, malware, or unauthorized scripts on OT-adjacent Windows assets.

-- Hunt: processes with live EtherNet/IP (44818) connections on OT-adjacent hosts
-- Expected: RSLinx Classic, FactoryTalk, Studio 5000, rslogix emulation tools
-- Flag anything else for triage
LET expected_procs = ("rslinx", "studio5000", "rslogix", "factorytalk", "rsview", "ftae")
SELECT Pid, Ppid, Name, Exe, CommandLine,
       netstat.RemoteAddr AS RemoteIP,
       netstat.RemotePort AS RemotePort,
       netstat.State AS ConnState
FROM netstat()
WHERE RemotePort == 44818
  AND NOT any(list=expected_procs, getter=\| Name =~ $getter)
ORDER BY Name

Any row returned is a process you did not expect talking to your control network bridge modules. In a healthy environment this query returns zero rows; anything else warrants immediate triage — check the binary's hash and signer before assuming malice, but treat unsigned executables holding 44818 sessions as presumptively hostile until proven otherwise.

Remediation / Verification Script

Since there is no firmware fix referenced in the advisory (all versions affected, mitigation is architectural), the highest-value script is one that validates your compensating control: are your 1756-ENBT modules reachable only from authorized sources, and are any of them exposed to the internet? Run the following from a management jump box against your OT asset inventory.

# Requires: admin creds on the management station, asset list, nmap on PATH
# Purpose: Enumerate 1756-ENBT reachability and flag modules exposed to
#          unauthorized VLANs (CVE-2025-10478 compensating-control audit)

$AssetCsv   = "C:\audit\ot-assets.csv"        # columns: IP,Hostname,Zone
$Authorized = @("10.10.20.0/24","10.10.30.0/24") # engineering + SCADA VLANs
$Report     = "C:\audit\enbt-exposure-$(Get-Date -f yyyyMMdd).csv"

$assets  = Import-Csv $AssetCsv
$results = foreach ($a in $assets) {
    $tcp = Test-NetConnection -ComputerName $a.IP -Port 44818 -WarningAction SilentlyContinue
    # UDP 44818 check via nmap (Test-NetConnection is TCP-only)
    $udp = (& nmap -sU -p 44818 --open -Pn $a.IP 2>$null) -match "open"
    [pscustomobject]@{
        Hostname      = $a.Hostname
        IP            = $a.IP
        Zone          = $a.Zone
        TCP44818Open  = $tcp.TcpTestSucceeded
        UDP44818Open  = [bool]$udp
        ReachableFrom = $env:COMPUTERNAME   # run from multiple VLANs for full picture
        AuditTime     = Get-Date -Format o
    }
}
$results | Export-Csv $Report -NoTypeInformation
$results | Where-Object { $_.TCP44818Open -or $_.UDP44818Open } |
    Format-Table Hostname, IP, Zone, TCP44818Open, UDP44818Open

Write-Host "`n[+] $(@($results | Where-Object {$_.TCP44818Open}).Count) modules reachable on TCP/44818 from $env:COMPUTERNAME" -ForegroundColor Yellow
Write-Host "[!] Any module reachable from OUTSIDE these zones is at risk: $($Authorized -join ', ')" -ForegroundColor Red

# Bonus: check public exposure of your IP space via Shodan CLI (if licensed)
# shodan search --fields ip_str,port "port:44818 net:<your.public.cidr>" 

Run this script from every network zone that could plausibly route to the OT environment — corporate LAN, guest Wi-Fi, vendor VPN concentrators, cloud site-to-site tunnels. A module answering on 44818 from the corporate LAN is a lateral-movement DoS waiting to happen; one answering from the internet is an incident report in waiting.

Remediation

Because all versions of the 1756-ENBT are affected, there is no patch-and-move-on path today. CISA's advisory directs organizations to the following posture; we have ordered these by defensive value:

1. Monitor Rockwell Automation's security advisory portal for a firmware update addressing CVE-2025-10478 and apply it at your next maintenance window once released. Check the CISA advisory page (ICSA-26-246-05) for vendor-referenced guidance and update availability.

2. Isolate EtherNet/IP traffic at the network layer — this is the primary control. Place all 1756-ENBT modules behind an industrial firewall or ACL boundary and permit TCP/UDP 44818 only from:

   • Engineering workstations running Studio 5000 / RSLogix
   • HMI and SCADA servers (FactoryTalk View, etc.)
   • Historians with legitimate CIP collection requirements
   • Inter-controller peers that legitimately exchange produced/consumed tags

   Everything else — corporate LAN, guest networks, cloud VPCs, vendor VPNs — should be denied by default. This single control neutralizes the remote attack vector entirely for sources that cannot reach the module.

3. Eliminate direct internet exposure. Query Shodan/Censys for your public address space on port 44818. Any hit on a 1756-ENBT is a critical finding: remove the NAT rule, move remote access behind a brokered jump solution with MFA, and treat the module as potentially already probed.

4. Plan for the recovery path. Since exploitation forces a manual restart, document the restart procedure for on-shift operations staff now: chassis location, safe-state behavior of the process when comms drop, and the authorized restart sequence. Mean-time-to-recovery on a crashed ENBT is an operations problem, not an IT problem — rehearse it.

5. Deploy passive ICS monitoring if you have not already. A Zeek/Suricata sensor or commercial OT IDS on a SPAN port watching 44818 gives you both the detection rules above and a forensic record if a module crashes under suspicious traffic conditions. Correlate module-down events with preceding traffic bursts — that pairing is your post-incident attribution evidence.

6. Follow CISA's standard ICS mitigations referenced in the advisory: minimize network exposure for all control system devices, locate control networks behind firewalls isolated from the business network, and use secure remote access methods (updated VPNs with MFA) where remote access is required.

7. Report suspected exploitation to CISA (central@cisa.gov or the ICS-CERT reporting portal) and Rockwell Automation PSIRT so exploitation telemetry for this CVE is tracked accurately across the community.

There is no CISA KEV-mandated remediation deadline for this CVE as of publication, but given the manual-restart recovery requirement and the sectors affected, we recommend completing the segmentation audit (step 2) within 30 days and treating any internet-exposed module as an immediate finding.

Related Resources

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