The landscape of industrial automation continues to evolve at a rapid pace, and with these advancements come ever-increasing cybersecurity risks. ABB Automation Builder, a prominent engineering suite widely adopted in the energy sector and critical infrastructure worldwide, now finds itself under scrutiny following the public disclosure of two severe vulnerabilities assigned CVE-2025-3394 and CVE-2025-3395. These findings are the subject of a comprehensive advisory issued by CISA and have raised urgent questions among system integrators, operators, and cybersecurity professionals about the broader implications for industrial control system (ICS) security.
ABB Automation Builder is a development environment designed for configuring, programming, and commissioning PLCs, automation controllers, and related devices. Because it serves as the digital nerve center for orchestrating critical infrastructure, weaknesses in its security posture can have cascading effects—potentially allowing malicious actors to tamper with user credentials or even modify automation code in ways that subvert safety and operational integrity.
The most pressing concern detailed in the CISA advisory revolves around “Incorrect Permission Assignment for Critical Resource,” mapped to the Common Weakness Enumeration (CWE-732). This class of vulnerability emerges when software components assign permissions to users or files in a manner that can be abused—often through the mismanagement of file access or incorrect configuration of authorization policies.
Both CVE-2025-3394 and CVE-2025-3395 ultimately stem from the way Automation Builder handles user management and device application files, with all versions confirmed to be affected. The technical nuances and potential business impacts of these vulnerabilities merit close attention.
The implications of this are significant. Since Automation Builder often acts as the conduit between operator intent and device behavior, overruling user management could pave the way for downstream attacks—ranging from unauthorized code uploads to intentional misconfiguration of critical safety controls.
One core strength of ABB’s product ecosystem—its flexibility and standardized approach to device programming—becomes a double-edged sword here. Since the engineering software suite serves as a “single-pane-of-glass” for configuration and deployment, a compromise at this layer can ripple rapidly through operational technology (OT) environments, escalating from an isolated human-machine interface (HMI) to widespread effects across process controllers, safety relays, and beyond.
This, on the surface, may seem to provide a measure of relief. Yet, the defense-in-depth lessons of past ICS breaches suggest otherwise. Attackers frequently exploit weak remote access protocols, spear-phishing, or supply chain weaknesses to gain initial footholds on engineering stations, at which point exploitation of these file-based vulnerabilities becomes trivial. Notably, no active exploitation or “in the wild” attacks have been reported to date, but history teaches that public disclosure of such high-severity flaws often marks the starting gun for organized threat actors to begin targeted campaigns.
Notably, none of these vulnerabilities are exploitable remotely in their default form, providing a degree of containment—though organizations are reminded of the ever-present possibility that local access may be a single exploit away.
Experts have long warned that the weakest link in the chain becomes the point of leverage for adversaries. Industrial file structures that lack cryptographic signing, access control, or robust tamper detection are now seen as prime attack vectors. ABB’s adoption of “Integrity” and “Encryption” settings reflects a general industry pivot towards defense-in-depth, but uptake varies widely among customer bases.
This isn’t a challenge unique to ABB; across the OT landscape, the lifecycle of automation and control software stretches well beyond the typical support timelines of IT products. Asset owners often deploy engineering workstations that persist in the field for decades, compounding the security debt of file-based vulnerabilities.
While ABB and CISA’s advisory is an encouraging example of industry transparency and coordinated defense, the ultimate responsibility for mitigation rests with asset owners, integrators, and frontline engineers. The path forward requires renewed vigilance—not only in applying recommended workarounds but in advocating for stronger, more resilient architectures that treat file-based configuration as a primary point of defense.
The stakes could hardly be higher. In an era when critical infrastructure faces continuous threats from both cybercriminals and state-sponsored adversaries, even “simple” mistakes in permission assignment can open doors to consequences that reach far beyond the digital realm, threatening not only data or intellectual property but the safety and reliability of essential services on which societies depend. For organizations that rely on ABB Automation Builder, the message is clear: review your defenses, harden your project files, and make file integrity a cornerstone of your industrial cybersecurity posture—before adversaries take the next step.
Source: CISA ABB Automation Builder | CISA
Unpacking the ABB Automation Builder Vulnerabilities
ABB Automation Builder is a development environment designed for configuring, programming, and commissioning PLCs, automation controllers, and related devices. Because it serves as the digital nerve center for orchestrating critical infrastructure, weaknesses in its security posture can have cascading effects—potentially allowing malicious actors to tamper with user credentials or even modify automation code in ways that subvert safety and operational integrity.The most pressing concern detailed in the CISA advisory revolves around “Incorrect Permission Assignment for Critical Resource,” mapped to the Common Weakness Enumeration (CWE-732). This class of vulnerability emerges when software components assign permissions to users or files in a manner that can be abused—often through the mismanagement of file access or incorrect configuration of authorization policies.
Both CVE-2025-3394 and CVE-2025-3395 ultimately stem from the way Automation Builder handles user management and device application files, with all versions confirmed to be affected. The technical nuances and potential business impacts of these vulnerabilities merit close attention.
CVE-2025-3394: User Management Overruled
The first vulnerability, CVE-2025-3394, has been rated a 7.8 out of 10 under CVSS v3 and 8.5 under the recently adopted CVSS v4 scoring system—an uncommonly high risk level demanding urgent consideration. At its core, the flaw lies in the storage of user management information within project files. While ABB employs robust encryption for password data, the actual mechanisms for managing access and permission rules are not adequately safeguarded. This opens a scenario where an attacker with the ability to modify the project file (whether through local access or via a compromised engineering workstation) could craft changes that effectively bypass the built-in user management—potentially granting themselves elevated privileges or undermining established protections.The implications of this are significant. Since Automation Builder often acts as the conduit between operator intent and device behavior, overruling user management could pave the way for downstream attacks—ranging from unauthorized code uploads to intentional misconfiguration of critical safety controls.
CVE-2025-3395: Application File Integrity Subverted
The sister vulnerability, CVE-2025-3395, has been assessed with a slightly lower but still critical CVSS v3 base score of 7.1 (8.4 in CVSS v4). This issue specifically impacts devices such as AC500 V2 and SM560-S, which rely on project application files managed by Automation Builder. The vulnerability enables an adversary to alter these files in a manner that permits bypassing of the software’s user management systems, again by manipulating file structure or metadata. Unlike opportunistic attacks that might target network weaknesses, these scenarios still require local permissions, but as industry security professionals well know, local access can often be chained from other remote exploits or supply chain attacks.Who Is at Risk? Global Impact Across Critical Infrastructure
ABB’s customer base is extensive, particularly within the energy sector—power generation, transmission, and distribution—where ICS and SCADA systems controlled by ABB products underpin grids in North America, Europe, Asia, and many other regions. The vulnerabilities are not limited by geography or industry; they affect any organization relying on Automation Builder for programming and deploying automation solutions.One core strength of ABB’s product ecosystem—its flexibility and standardized approach to device programming—becomes a double-edged sword here. Since the engineering software suite serves as a “single-pane-of-glass” for configuration and deployment, a compromise at this layer can ripple rapidly through operational technology (OT) environments, escalating from an isolated human-machine interface (HMI) to widespread effects across process controllers, safety relays, and beyond.
Severity, Attack Complexity, and the Role of Local Access
Both vulnerabilities are tagged with “low attack complexity” in the official advisory, a finding based on the observation that triggering the flaws requires only straightforward manipulation of project or application files. However, the required access vector is “local”—meaning the attacker must have access to the engineering workstation or another environment where Automation Builder project files are stored.This, on the surface, may seem to provide a measure of relief. Yet, the defense-in-depth lessons of past ICS breaches suggest otherwise. Attackers frequently exploit weak remote access protocols, spear-phishing, or supply chain weaknesses to gain initial footholds on engineering stations, at which point exploitation of these file-based vulnerabilities becomes trivial. Notably, no active exploitation or “in the wild” attacks have been reported to date, but history teaches that public disclosure of such high-severity flaws often marks the starting gun for organized threat actors to begin targeted campaigns.
Technical Analysis and Exploitation Pathways
A careful analysis of the vulnerabilities, referencing both the CISA advisory and independent research (such as the sources listed on the official CVE records), reveal several technical realities:- The entire user management schema within Automation Builder projects is exposed in a structure that allows modification by authorized file editors.
- Although credentials themselves are encrypted, permission assignments and access controls are not protected by any cryptographic signature or integrity check by default, except where specifically enabled by the project administrator.
- For the application file vulnerability (CVE-2025-3395), exploitability depends on the attacker’s capability to reverse-engineer the file formats used by ABB controllers—historically not an insurmountable barrier for well-resourced adversaries.
Attack Vectors in Realistic Industrial Environments
- Insider Threats: A disgruntled employee or contractor with workstation access modifies project files, elevating their permissions or seeding the control program with malicious logic.
- Supply Chain Compromise: An attacker intercepts engineering files in transit between integrators, contractors, or vendors—then plants backdoors or logic bombs before the code ever arrives on-site.
- Piggybacking on Remote Access: Many facilities rely on VPNs for maintenance access. An attacker who successfully compromises an external technician’s machine may find local engineering files trivially exposed.
Official Mitigations and Workarounds
ABB and CISA have published clear recommendations for risk mitigation, emphasizing preventive controls within the Automation Builder environment itself:- For CVE-2025-3394, administrators should enable the “Integrity” check within project settings, which prompts the software to verify modifications before accepting updates—a classic, though not infallible, defense against unauthorized alterations.
- For CVE-2025-3395, activating project “Encryption” ensures that application files, including those destined for AC500 V2 or SM560-S devices, cannot be meaningfully altered without access to valid credentials.
Notably, none of these vulnerabilities are exploitable remotely in their default form, providing a degree of containment—though organizations are reminded of the ever-present possibility that local access may be a single exploit away.
Broader Lessons and Systemic Risks
The disclosure of vulnerabilities in ABB Automation Builder exposes broader systemic issues that span the world of industrial automation.The Perils of File-Based Configuration
Storing critical user and device management data in mutable, insufficiently protected project files is not unique to ABB. File-based configuration is a legacy of an era where physical security and operational isolation—in other words, “air gapping”—were considered sufficient. In today’s digitally interconnected ICS environments, the attack surface has grown far beyond what these design choices can safely support.Experts have long warned that the weakest link in the chain becomes the point of leverage for adversaries. Industrial file structures that lack cryptographic signing, access control, or robust tamper detection are now seen as prime attack vectors. ABB’s adoption of “Integrity” and “Encryption” settings reflects a general industry pivot towards defense-in-depth, but uptake varies widely among customer bases.
Patch Gaps and the Legacy Challenge
ABB has stated that “all versions” of Automation Builder are affected. This leaves organizations relying on older, unsupported, or customized versions facing particularly acute challenges, since deploying workarounds or updating to newer releases may conflict with operational constraints or regulatory mandates. The advisories make no mention of a universal patch, suggesting that configuration hardening is the near-term solution.This isn’t a challenge unique to ABB; across the OT landscape, the lifecycle of automation and control software stretches well beyond the typical support timelines of IT products. Asset owners often deploy engineering workstations that persist in the field for decades, compounding the security debt of file-based vulnerabilities.
Notable Strengths in ABB/CISA Response
- Early and Transparent Disclosure: The public release of CVE information prior to confirmed exploitation allows organizations to prioritize defensive action now, rather than after an incident.
- Clear and Actionable Guidance: Both ABB and CISA offer specific, actionable steps—down to the project setting level—for immediate risk reduction.
- Emphasis on Defense-in-Depth: A holistic approach is promoted, recognizing that no single defense layer suffices in the evolving ICS threat landscape.
Persistent and Emerging Risks
Despite the strengths in response, several risks warrant scrutiny:- Mitigation Reliance on User Action: Solutions depend on system owners applying settings that are often overlooked or misunderstood. Without centralized enforcement, coverage is inherently patchy.
- Lack of Remote Exploit Pathways (for Now): While the vulnerabilities are presently local in nature, sophisticated adversaries could chain them with remote access or supply chain attacks. Security teams should treat “local” vulnerabilities as potentially remotely exploitable, given enough time and motivation on the part of attackers.
- Legacy Asset Exposure: Organizations unable to update or reconfigure legacy instances of Automation Builder remain vulnerable with few alternatives beyond compensating controls and network isolation.
Recommendations for ABB Automation Builder Users
Immediate Steps
- Audit All Engineering Workstations: Verify the “Security” settings within Automation Builder projects, ensuring that both “Integrity” and “Encryption” options are enabled where possible.
- Isolate Automation Development Environments: Physically segment engineering workstations, minimize network exposure, and monitor for unusual file changes.
- Establish File Integrity Monitoring: Deploy tools to detect unauthorized or unexpected changes to Automation Builder project/application files.
Strategic Moves
- Review Supply Chain Security: Ensure that all contractors, integrators, and vendors adhere to strict file handling and transmission protocols; consider cryptographic signing for all project files.
- Advocate for Vendor Support: Engage with ABB and automation vendors to push for mandatory security controls and improved auditability in future releases.
- Invest in Training: Educate engineers and system administrators about the risks posed by file-based configuration, emphasizing secure configuration and detection strategies.
Incident Response Preparedness
- Develop Playbooks: Prepare response plans for scenarios involving suspicious changes to engineering files or anomalous device behavior linked to project imports.
- Coordinate with Authorities: Follow internal escalation procedures and report suspected incidents to CISA or relevant authorities for broader situational awareness and analysis.
Conclusion: A Wake-Up Call for ICS Security
The vulnerabilities in ABB Automation Builder serve as a timely reminder that the security of industrial automation and control systems fundamentally depends on the integrity of both the engineering environment and the files it produces. As industrial systems become increasingly intertwined with broader enterprise networks, the “local-only” designation of file vulnerabilities becomes less meaningful; threat actors will continue to probe every possible gap in segmentation, access control, and user awareness.While ABB and CISA’s advisory is an encouraging example of industry transparency and coordinated defense, the ultimate responsibility for mitigation rests with asset owners, integrators, and frontline engineers. The path forward requires renewed vigilance—not only in applying recommended workarounds but in advocating for stronger, more resilient architectures that treat file-based configuration as a primary point of defense.
The stakes could hardly be higher. In an era when critical infrastructure faces continuous threats from both cybercriminals and state-sponsored adversaries, even “simple” mistakes in permission assignment can open doors to consequences that reach far beyond the digital realm, threatening not only data or intellectual property but the safety and reliability of essential services on which societies depend. For organizations that rely on ABB Automation Builder, the message is clear: review your defenses, harden your project files, and make file integrity a cornerstone of your industrial cybersecurity posture—before adversaries take the next step.
Source: CISA ABB Automation Builder | CISA