A security issue exists within the 1715-AENTR EtherNet/IP Adapter

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'.

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-306 means 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.

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.

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()

Sources

1. CISA ICS Advisory ICSA-26-195-04
2. CISA CSAF JSON — icsa-26-195-04
3. Rockwell Automation Security Advisories portal
4. Rockwell 1715-AENTR product page
5. OpenCVE — 1715-AENTR EtherNet/IP Adapter CVE history
6. CWE-306: Missing Authentication for Critical Function
7. CISA guidance — Defense-in-Depth for ICS
8. ODVA CIP Security overview