Over 4,400 Rockwell PLCs Exposed Online, 22 Found in Water Attack Cities

The discovery of more than 4,400 Rockwell Automation programmable logic controllers directly accessible from the internet demonstrates how basic deployment failures continue to expose operational technology to potentially disruptive cyberattacks. Forescout identified 4,407 publicly reachable Rockwell controllers worldwide during an August 3, 2026 scan, including 2,844 devices located in the United States. Researchers also found 22 exposed controllers in cities affected by recent attacks against US water and wastewater utilities, although the available evidence does not establish that those particular devices were compromised. 

The distinction between exposure and confirmed compromise is important. An internet-facing PLC should not automatically be counted as an attack victim, and the presence of an exposed controller in an affected city does not prove that it was involved in a reported incident. Nevertheless, the findings reveal that thousands of industrial controllers remain reachable from networks where attackers can identify them, interact with their industrial protocols and potentially alter configuration depending on the device’s security settings. In operational technology environments, that exposure can affect pumps, valves, pressure controls, treatment processes, energy systems and other equipment with direct consequences for physical operations.

PLCs are designed to control machinery and industrial processes according to programmed logic. Unlike ordinary servers, they may influence whether a pump starts, a valve opens, a motor stops or an alarm is triggered. Interference with a PLC can therefore produce consequences extending beyond data theft or temporary application downtime. Manipulation can affect service availability, equipment safety, environmental conditions and public confidence in essential services.

Recent attacks on US water utilities illustrate this risk. The FBI and Environmental Protection Agency reported cyber incidents affecting water and wastewater organizations across multiple states beginning on July 27, 2026. Public reporting indicated that attackers changed controller network settings, set passwords that locked legitimate operators out and interfered with visibility or control of connected systems. These actions did not necessarily require exploitation of a previously unknown software vulnerability. In some cases, attackers appear to have abused controllers that were already accessible and insufficiently protected.

This point is significant because organizations often focus on vulnerability patching while overlooking architectural exposure. A fully patched PLC that is directly reachable from the public internet may still permit dangerous interaction through legitimate industrial protocols or engineering functions. Firmware updates address known defects, but they do not make public exposure safe. The first and most important control is ensuring that the controller cannot be reached directly by arbitrary internet users.

EtherNet/IP exposure creates a direct path to controllers

Many of the identified Rockwell devices exposed EtherNet/IP, an industrial communication protocol commonly associated with TCP and UDP port 44818. EtherNet/IP is used by engineering software, controllers, input-output devices and other automation components to exchange commands and operational data. It was developed for industrial environments in which devices were expected to communicate across trusted networks, not for direct exposure to hostile internet traffic.

When EtherNet/IP is publicly reachable, remote users may be able to identify the device model, firmware version, configuration and supported services. Depending on the controller and its security configuration, an attacker may also be able to establish a session, read data or modify settings using the same functions that legitimate engineers use.

The danger does not always arise from an exotic exploit. An attacker with the correct engineering software may interact with an exposed PLC through accepted vendor protocols. If authentication is absent, weak or improperly configured, the controller may not reliably distinguish an authorized engineer from a remote adversary.

This allows attackers to abuse legitimate functionality rather than trigger an obvious software crash. Security tools looking only for known exploit signatures may miss activity that resembles ordinary engineering communication. Detecting malicious use therefore requires understanding which systems are authorized to communicate with the PLC, what commands they normally issue and when configuration changes are expected.

Mobile carrier networks account for much of the exposure

Forescout found that more than 70 percent of exposed US-based Rockwell controllers were connected through large mobile carrier networks. Nineteen of the 22 devices found in cities affected by water utility incidents reportedly used the same mobile carrier.

Cellular connectivity is frequently used to support remote pumping stations, water towers, wells, pipelines and other infrastructure located far from central facilities. Mobile connections can provide a practical alternative where wired networks are unavailable or expensive. However, insecure carrier configurations can make devices publicly reachable through assigned IP addresses without the protections normally provided by an enterprise firewall.

Operators may assume that cellular connectivity is private simply because the device is not connected to the ordinary corporate internet service. That assumption can be dangerously incorrect. A cellular modem using a publicly routable address may expose the connected PLC directly unless the carrier, integrator or customer has implemented a private access point name, firewall policy, VPN or other protected architecture.

Organizations should verify how every cellular-connected OT device is addressed and routed. They should not rely on verbal assurances that a mobile network is private or secure. Internet scanning from an external location can confirm whether the controller or modem is actually reachable.

Where remote access is required, cellular-connected systems should use private APNs, encrypted VPN tunnels or secure remote-access gateways that enforce identity, device and network restrictions. The modem itself should use strong unique credentials, current firmware and detailed logging. Default administrative passwords and remotely accessible management interfaces should be removed or restricted.

Shared deployment practices can create systemic exposure

The concentration of exposed controllers on the same carrier may indicate that several utilities or integrators used similar deployment architectures. A common cellular provider is not itself evidence of compromise, but repeated network patterns can make large groups of devices discoverable and potentially vulnerable in the same way.

Third-party integrators often deploy remote monitoring systems across multiple customers using standardized configurations. This improves installation speed and reduces maintenance complexity, but it can also reproduce the same insecure settings across dozens of independent sites. If public addressing, default credentials or weak remote-access controls are included in the template, every customer may inherit the same exposure.

The FBI warned that similar third-party network setups could allow attackers to repeat successful compromises across multiple customers. An attacker who learns how one integrator configures cellular modems and PLCs may be able to identify other customers using the same addressing patterns, ports, credentials or engineering practices.

Utilities should therefore examine the security architecture provided by integrators rather than assuming that equipment installed by a specialist is securely configured. Contracts should define responsibility for internet exposure, modem security, credential management, firmware updates, logging and incident response. Customers should receive current network diagrams, device inventories, configuration backups and recovery procedures rather than depending entirely on knowledge held by the installer.

MicroLogix controllers represent a large portion of exposed systems

MicroLogix 1400 devices accounted for approximately half of the controllers identified by Forescout, while MicroLogix 1100 devices represented another eight percent. Both families were specifically named in federal warnings concerning attacks against water utilities.

The continued presence of MicroLogix 1100 controllers is notable because Rockwell Automation discontinued the product in April 2022. Discontinued equipment may remain operational for many years because industrial systems are designed for long service lives and replacing a controller can require engineering work, testing and planned downtime. However, end-of-life equipment generally receives diminishing vendor support and may not benefit from modern security improvements.

Legacy controllers are particularly risky when their deployments depend on insecure protocols, weak authentication or outdated network designs. Even when no exploitable software vulnerability is present, the device may lack capabilities now considered essential, such as modern identity controls, encrypted management, comprehensive logging or secure update mechanisms.

Organizations should maintain lifecycle plans for industrial controllers and avoid allowing discontinued equipment to remain indefinitely in exposed or critical roles. Replacement programmes should prioritize devices that are internet-accessible, control safety-sensitive processes or cannot support effective authentication and network protection.

Older firmware increases exposure to known vulnerabilities

Forescout determined that 19 of the 22 controllers located in affected cities appeared to run firmware susceptible to CVE-2017-16740. The vulnerability is a Modbus TCP buffer overflow affecting MicroLogix 1400 Series B and C controllers running firmware revision 21.002 and earlier. Rockwell corrected the issue in revision 21.003.

Researchers could not determine whether Modbus TCP was enabled on the exposed devices, which is required for exploitation of this specific flaw. The presence of vulnerable firmware therefore does not prove that CVE-2017-16740 was exploitable on each controller or used in recent attacks. Nevertheless, operating years-old firmware on an internet-facing PLC creates an avoidable layer of risk.

Asset owners should identify the exact hardware series, firmware revision and enabled protocols for every controller. Firmware updates should be tested carefully because changes to industrial equipment can affect process reliability, communications and compatibility with engineering software. However, operational caution should not become a permanent excuse for leaving known vulnerabilities unaddressed.

Where immediate firmware updates are not possible, the controller should be isolated through network controls that prevent untrusted access to vulnerable services. Unused protocols such as Modbus TCP should be disabled. Security teams should also monitor for connection attempts and malformed traffic directed toward exposed industrial ports.

Attackers may not need a CVE

The recent water utility incidents demonstrate why OT security cannot depend entirely on vulnerability management. Forescout noted that the publicly described effects, including changing IP addresses and setting controller passwords, could be achieved through ordinary controller functions when the device is accessible and inadequately protected.

This type of attack is especially concerning because it may not trigger detection rules based on known exploit payloads. The attacker can use vendor engineering tools and supported protocol commands to make changes that appear technically valid.

US agencies previously reported that Iran-affiliated actors used legitimate engineering software, including Rockwell Automation Studio 5000 Logix Designer, to connect to exposed controllers. Once connected, the attackers could retrieve project files, modify logic and interfere with data shown through human-machine interfaces and supervisory control systems.

The use of legitimate tooling complicates attribution and detection. A command sent through Studio 5000 is not inherently malicious. Its legitimacy depends on who initiated it, from which system, during what maintenance window and with what authorization.

OT environments therefore require strict control over engineering workstations and management paths. Only approved devices should be able to communicate with PLC programming interfaces, and changes should occur through documented processes. Unexpected connections from hosted infrastructure, mobile networks or foreign locations should generate immediate alerts.

Changing PLC passwords can lock operators out

In several reported incidents, attackers reportedly configured passwords on controllers that previously had none. This prevented legitimate personnel from accessing the devices and complicated recovery.

A controller without a password may appear operationally convenient, particularly at small utilities where several technicians require rapid access. However, when the device is publicly reachable, the absence of authentication allows anyone who discovers it to become the first party to establish control.

Once an attacker sets a password, the organization may be unable to restore access without resetting the controller to factory defaults. This can erase the running configuration and project logic, requiring the operator to reload a known-good copy.

The ability to recover therefore depends on maintaining current offline backups of PLC project files. A configuration stored only on the controller itself is not a reliable backup because the device may become inaccessible, corrupted or physically damaged.

Organizations should regularly export controller logic and configuration files, validate that they can be restored and store them securely offline. Backups should include documentation of firmware versions, network settings, module configurations and dependencies on connected equipment.

Recovery procedures should be tested under controlled conditions. Discovering during an active water service disruption that the only project file belongs to a retired contractor is an avoidable but distressingly plausible outcome.

Project files may be modified by attackers

The FBI reported that at least one victim found discrepancies in PLC ladder logic across several sites, indicating that project files had been modified. Ladder logic defines how the controller responds to sensor readings and determines when industrial equipment should start, stop or trigger alarms.

Malicious changes can alter process behaviour while preserving the appearance that the controller is functioning normally. Attackers may disable alarms, change thresholds or manipulate shutdown logic. They may also alter values displayed to operators, creating a gap between the physical process and what appears on the HMI or SCADA screen.

This can delay recognition of the attack because operators may initially believe the problem is mechanical, electrical or related to faulty sensors. In water systems, inaccurate visibility could affect pressure, treatment levels, storage capacity or pumping operations.

Security teams should compare running controller logic against trusted offline baselines. Hashes or digitally verified project files can help identify unauthorized changes. Critical reusable code modules and Add-On Instructions should receive particular scrutiny because one modified component may influence several parts of the process.

Logic changes should require formal approval, authenticated engineering access and audit records. Organizations should also retain previous versions so they can determine when a suspicious modification first appeared.

Physical controller mode settings provide important protection

Rockwell recommends placing the controller’s physical mode switch in the Run position when programming changes are not required. Depending on the product, this can prevent remote modification of controller logic.

Physical controls are valuable in OT environments because they cannot normally be bypassed through ordinary network access. An attacker may still read information or attempt denial-of-service activity, but preventing remote programming significantly limits the ability to manipulate the process.

The setting must be incorporated into operating procedures because maintenance teams may leave controllers in Remote or Program mode after legitimate work. A technically available security feature provides little value when routine practice keeps it disabled.

Organizations should document when changes require the controller to be placed into a programmable state and ensure that it is returned to the secure operating position afterward. Where supported, software-based protections and change locks should complement the physical switch.

Internet discovery should be performed proactively

The fact that independent researchers can find thousands of exposed controllers means attackers can locate them using the same techniques. Search engines for internet-connected devices can identify EtherNet/IP services, controller models, firmware data and network providers without scanning every address manually.

Organizations should regularly examine their external attack surface from outside the corporate and OT networks. Searches should include public IP ranges, cloud systems, cellular addresses and infrastructure operated by third parties.

Internet exposure may result from temporary troubleshooting rules, replacement cellular modems, forgotten port forwarding or changes made by an integrator. A device that was isolated when installed may become reachable later after unrelated network maintenance.

External discovery should therefore be continuous rather than a one-time audit. Every publicly accessible industrial protocol should have an identified owner and documented business justification. Unknown or unnecessary exposure should be removed immediately.

Removing internet access must be done carefully

Taking controllers off the public internet is the most important recommendation, but changes to operational technology require planning. An incorrect firewall rule or network modification can interrupt legitimate monitoring and control.

Asset owners should identify which systems communicate with each PLC and establish a protected replacement path before removing existing connectivity. Remote access can be moved behind a firewall, VPN, private cellular network or industrial demilitarized zone.

The final architecture should permit only required communication between known endpoints. Broad access from the corporate network or any authenticated VPN user remains unnecessarily risky.

Changes should be coordinated with operations personnel and tested to ensure that monitoring, alarms and safety functions remain available. OT security improvements should reduce cyber risk without creating unplanned physical disruption.

Segmentation limits the consequences of compromise

Industrial control networks should be separated from business systems, public networks and unrelated OT zones. A compromised office computer should not communicate directly with PLC programming interfaces, and an exposed field controller should not provide a route into the complete utility network.

Firewalls should restrict traffic according to source, destination, protocol and operational need. Engineering access should pass through controlled jump servers with multi-factor authentication and detailed session logging.

Remote support vendors should receive time-limited access to specific devices rather than permanent connectivity to the entire OT environment. Shared vendor accounts should be replaced with individual identities so every action can be attributed to a named technician.

Segmentation cannot prevent every attack against an exposed controller, but it can prevent one compromised site from becoming a path toward other plants, central SCADA servers or business systems.

Monitoring must account for legitimate engineering protocols

Traditional IT intrusion detection may not understand industrial protocols or identify unsafe configuration changes. OT-aware monitoring can establish a baseline of normal controller communication and identify unexpected programming commands, firmware transfers or project file uploads.

Security teams should alert when new systems communicate with EtherNet/IP ports or when engineering operations occur outside approved maintenance windows. Changes to controller mode, IP configuration, passwords and project logic should receive immediate attention.

Network monitoring should also identify communication with known malicious infrastructure and unusual connections from hosting providers or foreign networks. However, location alone should not determine legitimacy because attackers may use domestic cloud or mobile services.

Logs from cellular modems, remote-access gateways, firewalls, engineering workstations and SCADA systems should be collected centrally. Local records on a compromised controller or workstation may be incomplete or altered.

Manual operational checks remain important

OT security cannot rely only on digital alerts. Operators often recognise physical irregularities before cybersecurity systems do. Unexpected pump behaviour, pressure changes, alarm inconsistencies or differences between local gauges and HMI displays may indicate manipulation.

Organizations should define procedures for comparing digital readings with independent physical measurements when cyber interference is suspected. Manual control options and safe shutdown procedures should remain available.

Operational staff should know whom to contact when controller access fails or project logic appears inconsistent. Cyber incident response plans must include engineers who understand the physical process, not merely IT personnel examining network logs.

The goal is to maintain safe operations while preserving evidence and removing attacker access. Disconnecting a device without understanding the process may create additional hazards, whereas leaving a compromised controller in operation may allow continued manipulation.

Small utilities require practical support

Water and wastewater utilities frequently operate with limited budgets, small technical teams and equipment installed many years earlier. Remote connectivity may have been introduced to reduce travel between geographically distributed sites and enable contractors to provide support.

These operational realities help explain why insecure exposure persists, but they do not reduce the consequences. Small utilities often provide essential services to communities and may lack extensive redundancy when a controller becomes unavailable.

Government agencies, vendors, carriers and integrators need to provide practical guidance that can be implemented without requiring every utility to maintain a full OT security operations centre. This includes tools for identifying exposed devices, secure reference architectures, affordable private cellular connectivity and clear recovery procedures.

Mobile carriers can also play a role by notifying customers when industrial protocols are publicly exposed and offering private network options as the default for OT deployments. Integrators should stop treating public IP connectivity as the simplest universal solution for remote maintenance.

Incident response should assume controller integrity may be lost

Organizations discovering an internet-exposed PLC should not merely close the firewall rule and assume the issue has been resolved. Historical logs should be reviewed to determine whether unknown systems connected to the device or modified its configuration.

The running project should be compared with a trusted offline copy. Passwords, network settings, firmware versions and controller modes should be verified. HMIs and SCADA systems should be checked for inconsistent or altered data.

Where compromise is suspected, the organization should follow vendor recovery procedures, which may require resetting the controller and restoring a known-good project. This should occur with operational personnel present because resetting the device can interrupt the controlled process.

Connected engineering workstations should also be investigated. An attacker may have installed remote access or stolen project files and credentials from supporting systems. Restoring the PLC alone does not remove persistence established elsewhere.

The broader cybersecurity lesson

The exposure of more than 4,400 Rockwell PLCs shows that critical infrastructure remains vulnerable not only because of sophisticated zero-day exploits but also because devices designed for trusted industrial networks have been connected directly to the internet.

Recent attacks against water utilities demonstrate that adversaries can cause disruption through ordinary engineering functions when controllers are accessible and inadequately protected. They may change IP addresses, set passwords, retrieve project files or modify logic without exploiting a software defect.

This makes internet exposure itself the primary vulnerability. Firmware updates, strong credentials and monitoring remain necessary, but none of them justify placing a PLC directly on a public address.

Organizations should remove public connectivity, secure cellular deployments, enforce segmentation, restrict engineering access and maintain current offline copies of controller logic. They should verify physical mode settings, monitor for configuration changes and test recovery procedures before an incident occurs.

The presence of older MicroLogix controllers and vulnerable firmware further shows how lifecycle management and architecture must be considered together. Replacing every legacy PLC immediately may be unrealistic, but isolating it from arbitrary internet access is both achievable and essential.

The findings do not prove that all 4,407 controllers were compromised, nor do they establish that the 22 devices in affected cities were involved in the reported water attacks. They do prove that thousands of industrial controllers remain discoverable and reachable from the public internet during a period of active targeting against exactly this type of equipment.

An attacker should not be able to reach a controller operating a water pump from the same internet connection used to browse an ordinary website. When that is possible, the organization has removed nearly every obstacle between hostile intent and physical infrastructure.

Industrial cybersecurity begins with knowing which devices exist, how they are connected and who can communicate with them. The continued exposure of thousands of Rockwell PLCs shows that these basic questions remain unanswered in too many environments. Attackers are unlikely to wait patiently while asset owners finish the inventory.

Forescout found 22 internet-facing Rockwell Automation programmable logic controllers (PLCs) in cities hit by recent cyberattacks on US water utilities. Nineteen used the same mobile carrier network. Its August 3 scan counted 4,407 exposed Rockwell controllers worldwide, including 2,844 in the United States, but Forescout could not confirm any were compromised. That figure counts exposed

Source: Over 4,400 Rockwell PLCs Exposed Online, 22 Found in Water Attack Cities via The Hacker News — published 06 Aug 2026.