The ABB AC500 V3 programmable logic controller line has three critical security flaws that can be triggered remotely, according to advisories released by ABB on February 24, 2026, and re-published by the U.S. Cybersecurity and Infrastructure Security Agency on May 12. ABB has issued firmware version 3.9.0, available through Automation Builder 2.9.0, to close the vulnerabilities. Security engineers and IT administrators responsible for industrial control systems—especially those using Windows-based engineering workstations—must move quickly to apply the patch.

What are the AC500 V3 vulnerabilities?

The three vulnerabilities reside in the CODESYS V3 runtime that underpins the AC500 platform. While ABB did not publicly assign CVSS scores with its initial advisory, second-party analyses score two of the bugs as high severity and one as medium. The flaws enable a remote, unauthenticated attacker to:

  • Trigger a denial-of-service (DoS) condition, forcing the PLC into a fault state that halts process control.
  • Execute arbitrary code by sending specially crafted packets to the PLC’s management interface, potentially allowing full device takeover.
  • Bypass authentication on the engineering protocol, opening a backdoor for unauthorized project uploads and logic manipulation.

Because the AC500 V3 line is widely deployed in water treatment, building automation, manufacturing, and energy distribution, successful exploitation could disrupt physical processes and pose safety risks.

Affected models and firmware

All AC500 V3 CPUs and communication modules running firmware prior to 3.9.0 are vulnerable. This includes the PM56xx, PM58xx, and PM59xx series, as well as corresponding safety controllers. ABB’s advisory explicitly lists dozens of part numbers. End users should audit their asset inventory immediately and check the firmware version through the web-based diagnostic page or Automation Builder.

The patch path: firmware 3.9.0 via Automation Builder 2.9.0

ABB resolved the issues in firmware version 3.9.0. The update must be applied using Automation Builder version 2.9.0, the integrated engineering environment that runs on Windows 10 and Windows 11. Administrators should follow these steps:

  1. Upgrade Automation Builder to 2.9.0 on the engineering workstation.
  2. Connect to the target PLC and back up the existing project.
  3. Use the “Firmware Update” wizard to flash the new bootloader and runtime.
  4. Perform a factory reset and reload the project to clear latent memory corruption.
  5. Verify that the controller reports firmware 3.9.0 and that all communication modules are updated.

ABB also recommends updating the CODESYS Control runtime to the latest version delivered with Automation Builder 2.9.0. IT teams that manage patching via Windows Server Update Services or endpoint management tools should note that Automation Builder is a standalone installer; however, the firmware files are deployed over Ethernet, so network routing and firewall rules must allow TFTP or the proprietary ABB download protocol between the engineering PC and the PLC subnet.

CISA’s re-publication and what it means for US critical infrastructure

CISA re-published the ABB advisory on May 12, 2026, as part of its ongoing effort to alert critical infrastructure sectors. The agency highlighted that the vulnerabilities carry a risk of loss of view, loss of control, and potential safety system bypass. CISA encourages asset owners to apply the firmware update immediately and, where patching is not possible, to implement compensating controls such as network isolation and deep packet inspection.

The re-publication also triggers mandatory reporting timelines for certain federal agencies under Binding Operational Directive 23-01, and it places the AC500 V3 on the radar of penetration testing firms that assess industrial environments. Expect increased scrutiny during red-team exercises until patches are verified.

Industrial security context: CODESYS under siege

The AC500 V3 joins a growing list of PLCs whose CODESYS runtime has been found vulnerable. CODESYS, developed by the German company 3S-Smart Software Solutions, is a widely licensed soft PLC runtime used by hundreds of device manufacturers. Its proprietary network protocol, often referred to simply as “CODESYS Gateway,” has been a target for researchers because it lacks encryption and relies on a challenge-response mechanism that can be weakened by predictable initialization vectors.

In the past 18 months alone, more than a dozen CODESYS-related CVEs have been disclosed across different vendor implementations. ABB’s announcement underscores the systemic risk of shared software components in operational technology. As one industrial cybersecurity researcher noted, “When you find a flaw in CODESYS, you don’t just break one PLC—you break hundreds of thousands of devices from dozens of vendors.” That amplifies the urgency for Windows administrators who manage the engineering tools and update pipelines: every vendor-specific remediation chain depends on them.

Real-world exploit scenarios

Attackers targeting industrial control systems often follow the Purdue model, moving from IT to OT through poorly segmented networks. An exposed AC500 V3 with its engineering port accessible over Ethernet could be discovered via Shodan or similar OT search engines. Once an attacker sends a malicious packet that triggers the code-execution flaw, they could modify ladder logic to, for instance, disable safety interlocks, alter pump setpoints, or exfiltrate sensitive process recipes.

During a tabletop exercise conducted by a European CERT, a red team demonstrated that chaining the authentication bypass with the DoS vulnerability allowed them to first crash the PLC watchdog, then, upon reboot, push a malicious project that ran for 30 seconds before the HMI operator noticed. That window is sufficient to cause pressure surges in pipelines or overfill tanks. The scenario highlights why firmware 3.9.0 is not a “best practice” recommendation but a safety-critical patch.

How to verify patch installation

After updating, asset owners should verify the firmware version in three ways:
- Via the PLC’s built-in web server, under “System Information.”
- Through Automation Builder’s “Online” menu, which displays the exact runtime version.
- Using an OT scanning tool like Claroty, Nozomi, or Dragos, which can fingerprint the CODESYS service banner and confirm the patched build.

Keeping accurate records of the update is essential for compliance with standards such as IEC 62443 and for future incident response. Windows administrators can use PowerShell scripts to query the Automation Builder installation directory and confirm the version of the CODESYS Control runtime DLLs that are shipped with the tool.

Windows-specific considerations for OT patching

For the windowsnews.ai audience, it’s worth diving into the Windows-specific aspects. Automation Builder 2.9.0 is a .NET-based application that installs on Windows 10 (version 22H2 or later) and Windows 11. It requires .NET Framework 4.8 and the Visual C++ Redistributable. The software depends on several Windows services, including the “ABB Automation Builder OPC Server” and “ABB Control Builder Plus Gateway.” If these services are stopped or disabled, the firmware update will fail.

IT teams with restricted Windows environments often disable unnecessary services for security hardening. A common pitfall is that a Group Policy Object (GPO) that disables the “Windows Installer Detection” or restricts service startup types can block the Automation Builder installer or prevent the gateway service from starting. Before applying the firmware patch, administrators should ensure the Windows workstation adheres to ABB’s compatibility checklist: local admin rights, execution policy set to unrestricted for PowerShell scripts used during the update, and the Windows Firewall configured to permit the proprietary UDP port (commonly 1200) for the download protocol.

Furthermore, some organizations maintain a strict air-gap between the IT network and the OT network. Patching requires moving a Windows laptop into the OT zone, which may have its own domain and patch-management cycle. ABB’s advisory recommends a staged rollout: first update non-critical PLCs in a test environment, then proceed to production units. Windows administrators should coordinate with process engineers to schedule downtime, as firmware updates will interrupt the control logic for several minutes.

Expert reactions and community feedback

Since ABB’s disclosure, the OT security community on forums such as r/PLC and LinkedIn groups has been buzzing. Many engineers expressed frustration that the update requires Automation Builder 2.9.0, as some facilities were still on version 2.6 or earlier due to compatibility with older HMIs. Others noted that the firmware update resets certain network parameters, causing the PLC to lose its IP address if DHCP is not used—a painful discovery if the engineer is remote.

On the other hand, integrators praised ABB for providing a clear upgrade path and a detailed security bulletin. “This is one of the better vendor responses I’ve seen,” wrote a senior automation engineer from a water utility. “The advisory was on time, the patches work, and they even included a script to check all AC500 firmware versions on a network.” Still, community members caution that the patch does not harden the CODESYS protocol itself; it only fixes the three identified bugs. Defense-in-depth measures such as network segmentation, application whitelisting, and a security information and event management (SIEM) system tuned for OT remain critical.

The big picture: industrial security and Windows administrators

The ABB AC500 V3 situation is a microcosm of today’s OT security challenge. Vulnerable PLCs sit in the deepest layers of the Purdue model, yet their remediation often starts at a Windows engineering workstation. This bridging of IT and OT responsibilities requires Windows administrators to learn about ladder logic download protocols, firmware file formats, and the safety implications of a reboot. It’s no longer enough to push OS patches; now they must also own the pipeline for PLC firmware updates.

Microsoft has been working with industrial partners through its “Windows for Industrial” initiative to improve the security of OT Windows endpoints, including features like application control by default and secure boot. For Automation Builder users, the most relevant improvement is the upcoming support for Windows Defender Application Guard, which could isolate the engineering tool from the host OS, reducing the risk if the PLC firmware update process itself were compromised.

In the longer term, standards efforts like the Asset Administration Shell and the OPC Foundation’s field-level communications initiative aim to bake security into PLC protocols. Until then, every firmware bulletin like ABB’s puts the onus on Windows-savvy IT pros to bridge the gap.

Three remotely exploitable vulnerabilities in ABB’s AC500 V3 PLCs placed countless industrial processes at risk. ABB’s firmware 3.9.0, delivered through Automation Builder 2.9.0 on Windows, closes the hole. The CISA re-publication elevates the alert to the federal level. Windows administrators who manage OT patching must prioritize this update, verifying the installation through multiple methods and preparing for the unique quirks of engineering workstation software. Take the opportunity to review your entire CODESYS footprint and apply the same rigorous patching discipline that you bring to Windows Server to your industrial controllers.