01 · The Real Story
The industrial equivalent of leaving a factory-reset button on the outside of the building, wired to the assembly line
The Rockwell Automation 1715-AENTR is a redundant EtherNet/IP adapter that fronts a bank of I/O modules on ControlLogix/GuardLogix systems — the thing that actually reads sensors and drives valves, motors, and safety interlocks. Firmware versions 3.003 and earlier ship with a network-reachable debug port that requires no authentication and exposes an intrusive CLI. From that CLI an unauthenticated attacker on the same L2/L3 segment as the device can read or delete files, kill running tasks, modify device memory, and directly change I/O states — meaning they can lie to the controller about a tank level or force an output that opens a breaker.
There is no published vendor CVSS in the assessment intake, but this is a textbook CWE-306 (Missing Authentication for Critical Function) on a component whose entire job is driving physical process I/O. Any severity below CRITICAL misrepresents the blast radius. The only reason the exposed-population count looks small is that these devices should never be internet-facing — but inside an OT VLAN, they typically are wide-open to anything that shares the cell/area zone. Vendor severity, once published, will match reality; if anything, CVSS understates the *safety* dimension because it has no metric for 'operator opens a relief valve remotely'.
"Unauthenticated debug port on an OT I/O adapter that lets attackers flip physical I/O states. This is a safety event, not a patch ticket."
02 · The Attack Path
5 steps from start to impact.
STEP 01
Reach the OT cell/area zone
The attacker needs IP reachability to the 1715-AENTR's EtherNet/IP interface. In a Purdue-model-compliant environment that means a foothold on an engineering workstation, HMI, historian, or jump host in Level 2/3, or an unsegmented IT-to-OT flat network. Common entry paths: phishing an engineer, VPN into a poorly firewalled remote-support portal, or a compromised third-party integrator laptop.
Conditions required:
- L3 reachability to the adapter's IP
- No ACL/firewall isolating the debug port TCP service
Where this breaks in practice:
- Purdue-segmented networks with a properly configured IDMZ block IT-side attackers
- Cell/area firewalls (Rockwell Stratix, Cisco IE, Fortinet Rugged) with allow-lists usually limit non-CIP traffic
Detection/coverage: Passive OT monitors (Claroty, Nozomi, Dragos, Tenable OT) fingerprint 1715-AENTR by CIP identity; any new source talking to the debug port is anomalous
STEP 02
Enumerate the debug service
The attacker port-scans the adapter to find the non-CIP debug port. Because the service requires no authentication, a simple
nmap -sV or a Metasploit auxiliary module will confirm the CLI banner. No credential stuffing, no session token, no MFA — the port answers to anyone who can TCP-connect.Conditions required:
- Ability to send arbitrary TCP to the device
- Debug service running (default on affected firmware)
Where this breaks in practice:
- Rockwell CIP Security (if enabled and rolled out) would tunnel/authenticate control traffic, but debug port is out-of-band and typically not covered
Detection/coverage: Any TCP scan of an OT device generates high-fidelity alerts in Dragos/Nozomi/Claroty; sensor placement in the cell zone is prerequisite
STEP 03
Invoke privileged CLI commands
With no auth, the attacker issues CLI commands to read the on-device filesystem, drop new files, kill running firmware tasks, or write to memory. Custom scripting or a public PoC (none confirmed at time of writing) is trivial to build against a documented CLI. The adapter's own logs may be modifiable, giving the attacker anti-forensics leverage.
Conditions required:
- Debug port reachable from step 2
- Knowledge of the CLI command surface (reverse-engineered from firmware or leaked docs)
Where this breaks in practice:
- None inside the device — this is the *entire point* of CWE-306
Detection/coverage: Command-and-response is over cleartext; deep-packet-inspection OT sensors can decode and alert on non-CIP CLI syntax
STEP 04
Manipulate physical I/O
The CLI allows direct write to I/O state. The attacker can force an output high or low regardless of what the ControlLogix program says, effectively bypassing the PLC's process logic. Depending on what the I/O drives — pumps, valves, motor starters, safety-related outputs on a paired GuardLogix — the impact ranges from a nuisance trip to a genuine process safety event.
Conditions required:
- Successful CLI access
- I/O modules wired to consequential equipment (typical)
Where this breaks in practice:
- Independent safety instrumented systems (SIS) on a separate SIL-rated bus limit the *safety* blow but not the *operational* blow
- Mechanical interlocks and PSVs are the last line of defense
Detection/coverage: SCADA historians and alarm servers will see the process deviation; whether the SOC connects it to the adapter compromise depends on OT/IT log correlation maturity
STEP 05
Persist / propagate
File-write primitives let the attacker plant modified firmware artifacts or persistence hooks that survive controller reboots. From this pivot, adjacent 1715-AENTR units on the same rack backplane and other CIP-speaking devices are one hop away. This is how a single compromised adapter becomes a plant-wide OT incident.
Conditions required:
- Write access to non-volatile storage on the adapter
- Backplane visibility to peer modules
Where this breaks in practice:
- Rockwell's signed-firmware controls on newer FW blunt naive firmware swaps but do not prevent runtime memory tampering
Detection/coverage: Firmware hash drift is detectable via Claroty/Dragos configuration baseline monitoring; few plants actually enable this
03 · Compensating Control
1
Block the debug port at the cell/area firewall now — Identify the debug TCP port(s) exposed by the adapter (Rockwell PCDC KB or capture with a passive OT sensor), then deny all traffic to it except from a named engineering-workstation subnet. Deploy within 3 days per noisgate mitigation SLA.
2
Enforce strict allow-listing on EtherNet/IP paths — Restrict CIP (TCP/44818, UDP/2222) and any non-CIP management traffic to known controllers, HMIs, and engineering workstations. On Stratix/Cisco IE switches use port-security and MAC pinning; on Fortinet Rugged / Palo IoT firewalls use application-ID filters. Deploy within 3 days.
3
Enable CIP Security where the fleet supports it — CIP Security provides authenticated, integrity-protected control traffic. It does not cover the debug port directly but hardens the surrounding attack surface, and it is a prerequisite for defensible OT segmentation. Deploy within 3 days on any capable stack.
4
Deploy or tune passive OT monitoring to alert on debug-port traffic — Claroty CTD, Nozomi Guardian, Dragos, or Tenable OT — build a detection rule matching *any* TCP flow to the adapter outside of CIP/44818, and page the OT SOC on match. Deploy within 3 days.
5
Isolate remote-support VPN paths from the OT cell zone — Most real-world compromise begins with an integrator laptop or vendor VPN. Force those sessions through a jump host with MFA and session recording; do not let them terminate directly in Level 2/3. Deploy within 3 days.
6
Schedule firmware update to 3.011+ in the next maintenance window — This is the durable fix. Coordinate with process engineering because 1715-AENTR sits on redundant I/O — you can generally update one side at a time, but validate the update procedure in a lab first. Complete within 90 days per noisgate remediation SLA.
What doesn't work
- IT-side EDR — the adapter has no OS to run an agent on; endpoint controls are irrelevant to the device itself.
- Changing an application password on the ControlLogix controller — this vuln is on the adapter's debug port, not on the CIP application layer, and the debug service ignores controller credentials.
- Perimeter firewall / IDMZ alone — most attackers reach OT via lateral movement from a compromised engineering workstation, not from the internet; north-south controls do not stop east-west abuse.
- Assuming CVSS-BT temporal downgrade because no PoC exists — the CLI is trivially callable once reachable; absence of a public PoC today is not a control.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No confirmed exploitation as of 2026-07-15. No public campaigns attributed. OT-targeting APTs (VOLTZITE, ELECTRUM, CHERNOVITE) are known to weaponize Rockwell/EtherNet-IP surface — assume tooling exists privately. |
|---|---|
| Proof-of-concept | No public PoC on GitHub, ExploitDB, or Metasploit as of assessment date. CLI syntax is easily reverse-engineered from firmware image; expect PoC within 30–90 days. |
| EPSS | Not yet scored (freshly disclosed 2026-07-14). Expect low initial score — EPSS underweights OT because it trains on IT telemetry. |
| KEV status | Not KEV-listed as of 2026-07-15. Historically CISA adds ICS bugs to KEV only after confirmed ITW use. |
| CVSS vector (CISA) | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — 10.0 Critical per CISA ICSA-26-195-04. Network / low complexity / no privs / no UI / scope change / full CIA impact. |
| Affected versions | 1715-AENTR EtherNet/IP Adapter firmware ≤ 3.003 |
| Fixed version | Firmware 3.011 or later from Rockwell Automation PCDC |
| Exposure data | Shodan queries for port:44818 product:"Rockwell" return several thousand internet-exposed CIP devices globally; 1715-AENTR-specific counts are in the low hundreds but represent the tip of the iceberg — the real installed base is inside OT networks and invisible to internet scanners. |
| Disclosure | 2026-07-14 via CISA advisory ICSA-26-195-04 |
| Reporter | Rockwell Automation self-reported to CISA |
Sources.
- CISA ICS Advisory ICSA-26-195-04
- CISA CSAF JSON — icsa-26-195-04
- Rockwell Automation Security Advisories portal
- Rockwell 1715-AENTR product page
- OpenCVE — 1715-AENTR EtherNet/IP Adapter CVE history
- CWE-306: Missing Authentication for Critical Function
- CISA guidance — Defense-in-Depth for ICS
- ODVA CIP Security overview
05 · The Call
Final Verdict
= UNCHANGED to CRITICAL (9.8/10)
Why this verdict
- Role multiplier — OT I/O adapter, safety-adjacent: The 1715-AENTR *is* the interface between the controller and physical process equipment. A compromised chain ends in forced I/O states → process disruption or safety incident. This is on the canonical high-value-role list (OT/ICS/SCADA controllers) and pins the verdict floor at CRITICAL.
- Zero exploit friction on the device:
CWE-306means there is nothing to bypass — no auth, no session, no crypto. The only friction is *reaching* the device. - Network reachability is the sole gating factor, and inside a typical OT cell/area zone that gate is wide open. Segmentation between IT and OT reduces the exposed population but does not change what happens once an attacker is on the OT side (which is where phishing, VPN abuse, and third-party integrator compromise routinely land them).
- CISA-published CVSS confirms 10.0 (
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Our reassessed 9.8 nudges down only to reflect that most units are not directly internet-reachable — the technical severity is unchanged. - No compensating vendor control ships enabled by default on affected firmware; CIP Security (if deployed) does not cover the debug port.
Why not higher?
A pure 10.0 would assume drive-by internet reachability comparable to a Log4Shell-class bug. Realistic 1715-AENTR deployments sit behind at least one cell/area firewall and are not directly on the public internet, so mass-scan exploitation is unlikely. That single friction knocks the score to 9.8 but does not touch the CRITICAL bucket.
Why not lower?
Dropping to HIGH would require either (a) the affected role not being safety-adjacent, or (b) meaningful in-device friction. Neither applies: this is an I/O adapter and the vuln is missing-auth on a privileged CLI. Every enterprise operating GuardLogix / ControlLogix in energy, water/wastewater, or critical manufacturing has to treat this as a plant-safety issue, not an IT patch.
06 · Verification
Crowdsourced verification payload.
Run this from an auditor workstation on the same OT segment as the target adapter (never from IT). Invoke as python check_1715aentr.py 10.10.20.15 where the argument is the adapter IP. Requires Python 3.8+ and outbound TCP to the target; no credentials needed. Uses only CIP List Identity (UDP/44818) to fingerprint firmware revision — it does not actually touch the vulnerable debug port.
#!/usr/bin/env python3
# noisgate verification: CVE-2026-10577 — Rockwell 1715-AENTR debug-port CWE-306
# Sends a CIP List Identity request over UDP/44818 and parses the returned
# major.minor firmware revision. Compares against fixed version 3.011.
import socket, struct, sys
FIXED_MAJOR, FIXED_MINOR = 3, 11
CIP_PORT = 44818
TIMEOUT = 3.0
def list_identity(host: str) -> bytes:
# ENIP encapsulation header: command 0x0063 (ListIdentity), length 0, session 0
pkt = struct.pack('<HHIIQI', 0x0063, 0, 0, 0, 0, 0)
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.settimeout(TIMEOUT)
try:
s.sendto(pkt, (host, CIP_PORT))
data, _ = s.recvfrom(4096)
return data
finally:
s.close()
def parse_revision(pdu: bytes):
# Very rough parse: locate the CIP Identity item (type 0x000C) then jump to
# the Revision field (Major=1B, Minor=1B) which sits at a known offset.
idx = pdu.find(b'\x0c\x00') # item type 0x000C little-endian
if idx < 0 or idx + 40 > len(pdu):
return None
# ProductName length byte lives at offset+32 from item start; revision at +40
major = pdu[idx + 40]
minor = pdu[idx + 41]
return major, minor
def main():
if len(sys.argv) != 2:
print('usage: check_1715aentr.py <adapter-ip>', file=sys.stderr)
sys.exit(2)
host = sys.argv[1]
try:
pdu = list_identity(host)
except socket.timeout:
print('UNKNOWN: no CIP List Identity response')
sys.exit(3)
rev = parse_revision(pdu)
if not rev:
print('UNKNOWN: could not parse CIP identity payload')
sys.exit(3)
major, minor = rev
print(f'device firmware: {major}.{minor:03d}')
if (major, minor) < (FIXED_MAJOR, FIXED_MINOR):
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()