When the Project File You Opened This Morning Was the Attack

On July 21, CISA published an advisory covering three vulnerabilities in Rockwell Automation Studio 5000 Logix Designer — the Windows-based engineering environment used to program and maintain virtually every Logix 5000 controller in operation. The vulnerabilities span six major versions of the software, from V32 through V36.

If your organisation runs Rockwell controllers — and in North American manufacturing, water, and energy, the odds are high that it does — your engineering team opens ACD project files in Studio 5000 every day. They open files from system integrators, from equipment vendors, from the colleague on the previous shift who left the latest revision on the shared drive, from the USB stick the contractor handed them during commissioning.

That ACD file is now a potential exploit vector.

Three Vulnerabilities, One Pattern

The advisory catalogs three weaknesses, but they share a common thread. None requires network access. None requires elevated privileges. All execute through trusted, routine actions — opening a project file, running an external tool, or relying on a configuration that looked correct when it was written.

CVE-2026-9108 — Path Traversal in ACD Project Files (CVSS 7.3). Studio 5000 does not validate file names embedded within ACD project files. A maliciously crafted ACD file can include paths that escape the intended extraction directory during project opening, reaching %APPDATA% or the Startup folder. From there, arbitrary code execution on next login is a short step.

CVE-2026-9127 — Incorrect Authorization on External Tool Configuration (CVSS 8.2). Any authenticated user on the engineering workstation can modify the paths Studio 5000 uses to locate external executables — compilers, firmware tools, communication drivers. There is no privilege check on the configuration file. When the engineer launches a routine task like “Download to Controller,” the attacker code runs instead.

CVE-2026-9128 — Unquoted Search Path in External Tools (CVSS 8.2). Executable paths in the External Tools configuration are stored without quoting. Windows search path resolution means an attacker who places a malicious binary with a name matching the first word of the unquoted path — somewhere earlier in the system PATH — will have it executed when Studio 5000 invokes the tool.

Taken together, the three describe an engineering workstation that trusts its project files, trusts its configuration, and trusts the search path of its host operating system — all without verification.

The Attack That Looks Like Tuesday

Here is the scenario.

A system integrator emails your controls engineer an updated ACD project file — routine. The engineer saves it, opens it in Studio 5000, reviews the ladder logic. Nothing looks unusual. The project compiles. The download to the controller proceeds without errors.

What the engineer does not see is that the ACD file exploited the path traversal to drop a small binary into the Startup folder during project open. That binary, on next login, modifies the External Tools configuration to point to a second-stage payload. The second stage waits. It watches for the moment the engineer initiates a download to a specific controller — and when that moment arrives, it inserts an additional rung of logic into the program before it reaches the wire.

No antivirus flag fires — no known malware signature matches. No IDS alert triggers — all traffic uses authorised protocols from an authorised host. The engineering workstation, by every metric a signature-based tool can measure, is behaving exactly as it should.

This pattern is not limited to Rockwell. Siemens TIA Portal. Schneider EcoStruxure. GE Proficy. Every OT engineering environment that opens project files from external sources inherits this attack surface. The CVE numbers change. The structural problem does not.

Why Signatures Cannot See This

A signature-based detection system compares what is happening against a database of what has happened before that was bad. Every item in that database was unknown once — until someone got compromised, analysed the aftermath, and wrote it down.

The Studio 5000 advisory describes vulnerabilities for which, as CISA notes, “no known public exploitation specifically targeting these vulnerabilities has been reported to CISA at this time.” There is no malware hash to match because no public malware exists. A signature-based tool watching an engineering workstation today has nothing to look for.

But the deeper limitation is structural: the initial compromise — opening the malicious ACD file — generates no network traffic at all. It is a local file operation. The only network traffic comes later, when the compromised workstation begins issuing commands to controllers it should not be reaching, at times it should not be active, to devices it has never communicated with before.

That traffic is not malicious in pattern. It is anomalous in behaviour. And anomaly is invisible to a signature.

What a Behavioural Baseline Would See

A passive network detection and response platform, deployed at the control-system switch, learns the normal communication patterns of every device over weeks and months. From that model, it surfaces deviations no signature would catch:

An engineering workstation that has communicated exclusively with Line 3 controllers for eighteen months suddenly opening a connection to the safety controller on Line 7 — a device it has never touched.
A workstation whose history is 95% read-status queries suddenly issuing a program-download command at 11:47 PM on a Saturday.
The inter-packet timing of CIP conversations shifting from its characteristic rhythm — consistent with an intermediary intercepting and modifying traffic.

None of these requires knowing which CVE was exploited. None requires a signature for the specific payload. They require knowing what normal looks like — and flagging when reality diverges from it.

This is the category of detection that catches novel attacks: the ones without CVEs, without signatures, arriving through trusted tools and trusted workflows because the attacker understands that trust is the most reliable exploit surface in any OT environment.

The Machine Neither IT Nor OT Fully Owns

The engineering workstation occupies an uncomfortable position in most organisations. It is a Windows machine managed by IT, running industrial software that IT does not understand. It is patched on the IT schedule — which often means never, because the OT team cannot risk a Windows Update breaking the controller programming environment. Antivirus runs but excludes the directories where project files and engineering tools live, because those exclusions are necessary to make the software work.

It is a machine that neither IT nor OT fully owns — and that attackers understand perfectly.

The CISA advisory will prompt a round of patching. Studio 5000 V37 and the associated point releases will be tested and deployed. This is correct and necessary. But patching addresses the CVEs. It does not address the pattern. Next quarter, a different vendor will disclose different vulnerabilities in its project file parser. The fundamental attack surface — the trusted engineering workflow — remains because it cannot be removed. Engineers must open project files. They must download programs to controllers.

What can change is whether anyone is watching the network consequences when those trusted workflows are abused.

What the Advisory Really Tells Us

The advisory is a straightforward vulnerability disclosure: three CVEs, six affected versions, a set of patches. Every OT security team with Rockwell controllers should have a change ticket open.

But it also tells us something about the assumptions we have built into OT security — and how those assumptions create blind spots no patch can close. We assume the engineering workstation is trusted because it is operated by a trusted employee. We assume the project file is safe because it came from a known vendor. We assume that if something were wrong, a signature would catch it.

The attackers who target industrial environments do not share these assumptions. They understand the engineering workflow better than most security teams do. They know which file formats are exchanged, which tools open them, which directories are excluded from antivirus, and which network connections look normal to an IDS. They do not need to break encryption or spoof protocols. They need to craft a project file and wait for an engineer to open it.

That is not an attack on the network. It is an attack on the workflow. And defending it requires detection that works at the level of behaviour — because behaviour is the one signal the attacker cannot fully control.

Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.