CISA Warns DAQFactory CVE-2026-12390: Malicious .ctl Files Can Trigger Code Execution

On June 18, 2026, CISA published ICS advisory ICSA-26-169-02 warning that AzeoTech DAQFactory 21.1 and earlier contains a type-confusion flaw, CVE-2026-12390, that can let a malicious .ctl project file trigger arbitrary code execution when opened by a user. The advisory is narrow in technical scope but broad in operational implication: another industrial Windows workstation risk is hiding in the ordinary act of opening a file. For shops that treat engineering project files as trusted artifacts rather than executable-adjacent content, this is exactly the kind of bug that turns routine maintenance into a security boundary failure.

A Local Bug Still Becomes an Industrial Problem​

The first temptation with CVE-2026-12390 is to exhale. CISA says the vulnerability is not remotely exploitable, requires user interaction, and has no known public exploitation reported to the agency at the time of publication. In normal desktop software, that might push the issue down the priority list.
But DAQFactory is not normal consumer desktop software. AzeoTech describes DAQFactory as SCADA and HMI software used for measurement, automation, data acquisition, logging, alarming, networking, scripting, and operator interfaces across science and industry. In other words, it sits in the awkward middle ground between “just a Windows application” and “part of the control environment.”
That middle ground is where many ICS incidents become possible. The compromised object is not necessarily a PLC, drive, robot, or safety controller. It may be the engineering workstation, historian client, HMI design station, or operator PC that holds privileged project files and has trusted access to more consequential systems.
CISA’s scoring reflects that tension. The CVSS 3.1 score is 7.8, high severity, with a local attack vector and required user interaction. The CVSS 4.0 score rises to 8.4, also high, emphasizing the potential impact to vulnerable systems once the document is opened.
The practical reading is simple: this is not a wormable internet bug, but it is a credible foothold bug. In industrial environments, a foothold on the right Windows machine can matter more than a remote exploit against the wrong one.

---

The Dangerous File Is the One Everyone Already Trusts​

CVE-2026-12390 is a type-confusion vulnerability in DAQFactory versions 21.1 and prior. Type confusion is the class of memory-safety bug that occurs when software treats a resource or object as one type when it is actually another. In a file parser or project loader, that can become a pathway from malformed input to memory corruption and, in the worst case, code execution.
The important phrase in CISA’s advisory is not just “arbitrary code execution.” It is “specially crafted .ctl files.” DAQFactory project and control files are the kind of artifacts that flow naturally through support channels, integrator handoffs, lab environments, vendor troubleshooting, backups, and internal change-control workflows. They are not suspicious ZIP attachments from a stranger; they are the working material of the job.
That makes the vulnerability more useful to an attacker than its “local” classification might suggest. A malicious .ctl file could arrive as a project sample, a recovered configuration, a contractor handoff, an alleged fix, or a file copied from an old workstation. The attack path depends less on exposed services than on operational trust.
This is a recurring pattern in industrial software security. File formats become attack surfaces because engineering tools must parse complex state: screens, scripts, device definitions, logging rules, alarm logic, networking configuration, and custom user interface elements. The more expressive the file format, the more tempting it becomes to attackers looking for parser bugs.
DAQFactory’s own feature set helps explain the risk. Its value proposition is flexibility: live edits, custom screens, scripting, networking, data logging, Modbus and OPC support, and runtime distribution. Those are useful capabilities. They also mean a project file is not a passive text document in the way a plain CSV might be passive. It is closer to a compact bundle of operational intent.

CISA’s Mitigations Reveal the Real Security Boundary​

AzeoTech’s mitigations, as relayed by CISA, are striking because they do not begin with a patch command or version upgrade instruction. Users are discouraged from using documents from unknown or untrusted sources. They are encouraged to store .ctl files in folders writable only by admin-level users, use Safe Mode when loading documents that have been out of their control, and apply a document editing password to their documents.
Those recommendations are not glamorous, but they are revealing. They frame the project file itself as a security boundary. That is the right mental model for this flaw.
If a project file can trigger code execution, then file provenance becomes part of workstation hardening. Where the file came from, who could modify it, whether it was transferred over a trusted path, and whether it has been sitting in a shared folder with broad write access all become security-relevant facts. This is the sort of control that mature enterprise IT teams already apply to scripts and executables, but often forget to apply to industrial project files.
The admin-writable-folder guidance is especially important. Many industrial teams use shared directories as informal project vaults. If those shares allow broad write access, a compromised domain user, malware infection, or disgruntled insider does not need DAQFactory admin rights to create a dangerous condition. They only need to replace or plant a .ctl file that a legitimate engineer will later open.
Safe Mode, meanwhile, is a partial answer to a messy operational question: how do you inspect a potentially untrusted project without giving it the full run of the application environment? It is not a substitute for patching, sandboxing, or endpoint monitoring, but it is a useful reminder that “open the file and see what happens” is not an acceptable analysis method on a production-connected workstation.
The document editing password recommendation is more modest. Passwords on project files can reduce unauthorized modification, but they should not be mistaken for cryptographic provenance or malware protection unless the implementation actually provides those properties. In practice, the stronger control is still controlled storage, restricted write access, and disciplined file intake.

---

Industrial Workstations Remain the Soft Underbelly of OT​

The advisory lists Critical Manufacturing as the affected critical infrastructure sector and says deployments are worldwide. That does not mean every factory is vulnerable, nor does it mean DAQFactory is everywhere. It means the product class appears in environments where downtime, safety, production quality, and physical process integrity matter.
For Windows administrators, the uncomfortable lesson is that OT security is often decided on very familiar terrain. The endpoint is a Windows machine. The lure is a file. The impact is code execution. The mitigation stack looks like access control, backups, least privilege, application control, attachment hygiene, network segmentation, and monitoring.
The difference is consequence. On a normal office PC, arbitrary code execution can expose email, credentials, and business data. On an engineering workstation, it may expose recipes, process limits, device configurations, remote access tools, engineering software licenses, historian credentials, HMI projects, and trusted pathways into production networks.
This is why CISA repeats its familiar ICS guidance: minimize network exposure, place control systems and remote devices behind firewalls, isolate control networks from business networks, and use secure remote access such as updated VPNs when remote access is required. Those recommendations can sound boilerplate, but they are the second line of defense when a local application bug becomes a workstation compromise.
Segmentation does not fix type confusion. It limits what happens after exploitation. If the DAQFactory workstation has unrestricted SMB access across the plant, standing domain admin sessions, saved VPN credentials, and direct reachability to PLCs, then a document exploit becomes a much bigger problem. If the workstation is constrained, monitored, and separated from business email and internet browsing, the blast radius changes.
That is the real security argument here. File-based exploitation thrives when the same machine is used for engineering, email, web downloads, vendor support, and production administration. The fewer roles a workstation plays, the fewer chances a malicious file has to arrive and the less it can reach if it runs.

The Absence of Known Exploitation Is Not a Clean Bill of Health​

CISA says it has not received reports of known public exploitation specifically targeting this vulnerability. That is good news, but it should not become a reason for complacency. “No known public exploitation” is a visibility statement, not a proof of safety.
ICS environments are notoriously uneven in detection. Many plants do not have deep endpoint telemetry on engineering stations. Some cannot tolerate aggressive EDR policies. Others run older Windows builds, local admin workflows, shared accounts, and fragile vendor software that discourages frequent change. If exploitation occurred quietly inside a niche industrial workflow, it might not immediately appear in public reporting.
There is also a difference between exploitability and weaponization. A vulnerability that requires a crafted file and a user action may sit unused until an attacker has a reason to target a specific organization. For espionage, sabotage preparation, or ransomware staging, a malicious project file can be a tailored tool rather than a mass-market exploit.
The researcher acknowledgments matter in that context. CISA credits Rocco Calvi of TecSecurity and Trend Micro’s Zero Day Initiative for reporting the issue. ZDI’s involvement suggests the vulnerability came through a disclosure pipeline familiar with memory-corruption bugs in software parsers, not merely a theoretical audit note.
The absence of a remote vector also should not lull defenders. In many attacks, the first step is social engineering, supply-chain compromise, or credential theft; the second step is local execution. A malicious .ctl file fits cleanly into that chain, especially if the attacker already understands the victim’s engineering toolset.

DAQFactory’s Recent Vulnerability History Raises the Stakes​

This advisory does not land in isolation. DAQFactory has already appeared in prior CISA-related vulnerability reporting, including a December 2025 batch affecting release 20.7 build 2555 and earlier that covered multiple memory-safety issues such as out-of-bounds writes, out-of-bounds reads, uninitialized pointer access, heap-based buffer overflow, type confusion, use-after-free, and stack-based buffer overflow. Those issues also centered on malicious .ctl files and the possibility of code execution or information disclosure.
The new advisory moves the affected line to DAQFactory 21.1 and earlier and assigns CVE-2026-12390 to another type-confusion flaw. That matters because it suggests the file-parsing attack surface remains an area of concern even after previous rounds of disclosure.
This does not prove negligence by AzeoTech. Industrial software often carries long-lived parsing and compatibility code because customers rely on old project files, custom screens, historical configurations, and deployment-specific behavior. Breaking compatibility can be expensive for users. Preserving compatibility can be expensive for security.
That tradeoff is familiar across Windows industrial tooling. Applications built to keep plants running for decades often inherit assumptions from an era when project files were moved by trusted engineers, not adversaries. Today, those same files may move through cloud storage, remote support tickets, email, shared drives, USB media, and contractor laptops.
For defenders, the pattern is more important than any single CVE. When a product has recurring file-parser vulnerabilities, treat its project files as active content. That means scanning, staging, access control, offline review, and strict provenance should become routine, not exceptional.

---

The Patch Story Is Less Clear Than the Risk Story​

The advisory text provided for CVE-2026-12390 focuses on mitigation rather than a clearly named fixed version. That creates an uncomfortable operational gap. Administrators prefer the clean sentence: “Upgrade to version X.” Here, the immediate public guidance is about file trust, Safe Mode, admin-writable directories, and document passwords.
That does not mean users should stop at mitigations. It means they should check directly with AzeoTech for current builds, release notes, and vendor-specific remediation guidance, especially because DAQFactory versioning and deployment practices may vary across installed environments. In regulated or validated production settings, updating an HMI or DAQ platform may require testing, downtime windows, and rollback planning.
The absence of a simple upgrade instruction also changes how teams should triage. If a plant runs DAQFactory 21.1 or earlier and routinely receives .ctl files from outside parties, the exposure is higher than a lab machine that only opens internally controlled projects. If the workstation is connected to production networks and used for email, browsing, or vendor file exchange, the exposure rises again.
This is where IT and OT often talk past each other. IT asks whether the software is patched. OT asks whether the patch will break the process. The answer, in the interim, is compensating controls that reduce file exposure without pretending the underlying bug has disappeared.
A sensible near-term workflow would put untrusted .ctl files through a staging process before they reach production-connected systems. That could include receiving files on a non-production machine, verifying source and integrity, storing canonical project files in restricted repositories, and opening uncertain files only in the safest available mode. The point is not to turn every maintenance job into a bureaucracy. The point is to stop treating project files as harmless just because they have a familiar extension.

Windows Defenders Should Treat .ctl Files Like Scripts​

The Windows security world learned this lesson with Office macros, PowerShell scripts, MSI installers, LNK files, and compressed archives. A file does not need to be an .exe to be dangerous. It only needs to be parsed by a trusted application with enough complexity and privilege to make exploitation useful.
For DAQFactory users, .ctl should now live in that category. It is not simply a configuration blob. It is content interpreted by a powerful industrial application that may run on machines with operational access.
That classification has practical consequences. Endpoint rules should know where DAQFactory project files are allowed to live. File shares should restrict who can write or overwrite them. Backups should preserve known-good copies. Administrators should monitor sudden changes to project repositories, especially where files are opened by privileged users.
Application control can help, but it is not a complete answer. If the exploit runs inside the DAQFactory process, blocking unknown executables may not stop the first stage. It may still reduce post-exploitation tooling, credential theft utilities, or ransomware payloads. The best defense is layered: constrain the file, constrain the user, constrain the process, constrain the network.
This is also a moment to revisit local privilege. CVSS notes no privileges are required from the attacker, but the opened file executes in the context of the user running the application. If engineers routinely run DAQFactory as local administrator because old drivers, device interfaces, or vendor habits require it, the consequence of exploitation becomes more severe. Removing unnecessary local admin rights remains one of the least glamorous but most valuable controls in industrial Windows environments.

The Social Engineering Angle Is the Point, Not the Footnote​

CISA’s advisory repeats standard warnings about unsolicited links and attachments, recognizing email scams, and avoiding social engineering attacks. In some advisories, that language feels like wallpaper. Here, it is central.
The exploit path requires a user to open a file. That makes trust manipulation part of the vulnerability’s real-world viability. Attackers do not need to spray the internet if they can convince a technician, contractor, support engineer, or plant operator to open a project file that appears relevant to an active job.
The lure can be boring, which makes it effective. “Updated pump station screen.” “Recovered logger project.” “DAQFactory config from vendor.” “Please verify this control file before tomorrow’s run.” Industrial work is full of legitimate file exchanges that look exactly like that.
This is where generic phishing training often falls short. Telling users not to open unknown attachments is useful but incomplete when their job requires opening attachments from vendors, labs, integrators, and customers. The better control is a trusted intake path: files from outside the organization go to a staging location, are associated with a ticket or work order, and are opened first on systems that are not production-critical.
That process should not be designed as a punishment for engineers. It should be designed as a recognition that engineers are being asked to make security decisions under time pressure. A good workflow removes that burden by making the safe path the default path.

---

Critical Manufacturing Needs Better File Provenance​

Critical manufacturing has spent years improving network segmentation, remote access, asset inventories, and vulnerability management. File provenance still lags behind. That gap is increasingly hard to defend.
A plant may know which PLCs are on which subnet but not who last modified the HMI project file. It may require approval for a firewall rule but allow broad write access to a folder full of control projects. It may log VPN sessions but not alert when a DAQ application opens a file copied from a USB drive ten minutes earlier.
CVE-2026-12390 is a reminder that project artifacts deserve the same seriousness as executables. In many OT environments, they are more operationally important than executables because they define what the application does in the local process. A malicious change or maliciously structured file can exploit both software bugs and organizational assumptions.
The fix is not just technology. It is governance with enough technical enforcement to matter. Canonical project repositories should have owners. Changes should be attributable. Write access should be narrow. Copies used for testing should be labeled and separated from production versions. Old files should not float around shared drives as unnamed operational folklore.
For smaller teams, this can sound excessive. But the lightweight version is achievable: a restricted folder, a naming convention, a backup, a review step for external files, and a habit of not opening mystery projects on production-connected machines. Security programs often fail when they demand perfection. They work when they make the risky behavior slightly harder and the safe behavior normal.

The Score Says High, the Workflow Says Urgent​

CVSS is useful, but it cannot fully express operational context. A 7.8 local file-parsing vulnerability on an isolated lab PC is one thing. The same vulnerability on a DAQ workstation tied to production monitoring, trusted file shares, and remote support access is another.
That is why asset owners should triage CVE-2026-12390 by workflow, not just version number. Which systems open .ctl files? Which people receive them? Which files come from vendors or contractors? Which workstations are production-connected? Which users run with elevated privileges? Which shares allow broad write access?
Those answers will separate theoretical exposure from practical risk. They will also reveal whether existing controls are doing the job. If no one can say where DAQFactory project files live or who can modify them, this vulnerability has already done something useful: it has found a governance blind spot.
The right response is not panic. CISA says there is no known public exploitation and no remote exploitation path. But the right response is also not dismissal. File-based code execution in industrial tooling has a long shelf life because project files get archived, copied, reused, and reopened years later.
That means mitigations must apply to old files too. A dangerous .ctl file does not become harmless because it sits quietly in a backup share. If a vulnerable version of DAQFactory opens it later, the same risk returns. Industrial environments are full of long memory; attackers can exploit that patience.

---

The .ctl Advisory Leaves Plant IT With a Short, Concrete Checklist​

The immediate work is less about one dramatic emergency change and more about tightening the ordinary places where trust leaks into production systems. For DAQFactory users, the advisory turns file handling into a security control.

• Inventory DAQFactory installations and identify any systems running version 21.1 or earlier.
• Treat .ctl files from vendors, contractors, email, shared drives, cloud sync folders, and removable media as untrusted until their origin and integrity are verified.
• Move authoritative DAQFactory project files into locations writable only by administrators or tightly controlled engineering roles.
• Use DAQFactory Safe Mode for documents that have been outside organizational control or whose provenance is uncertain.
• Review whether DAQFactory users need local administrator privileges, especially on production-connected workstations.
• Confirm with AzeoTech whether a newer fixed build or additional remediation guidance is available for the affected deployment.

This is also the right time to check whether DAQFactory workstations are segmented from business networks, whether remote access paths are patched and controlled, and whether endpoint monitoring can see suspicious child processes or file activity around engineering applications.
CVE-2026-12390 is not the loudest kind of vulnerability, and that is precisely why it deserves attention. It lives at the intersection of trust, habit, and industrial convenience: a project file opened by the right person on the wrong machine. The next phase of OT security will not be won only by hiding controllers behind firewalls; it will be won by treating the humble engineering file as part of the attack surface, because increasingly, it is.

---

References​

1. Primary source: CISA
   Published: 2026-06-18T12:00:00+00:00
   
   

   AzeoTech DAQFactory | CISA

   www.cisa.gov
2. Related coverage: isssource.com
   
   https://www.isssource.com/azeotech-fixes-daqfactory
3. Related coverage: azeotech.com
   
   

   Features

   AzeoTech, maker of DAQFactory HMI / SCADA Software

   www.azeotech.com
4. Related coverage: gohighvoltage.com
   
   

   AzeoTech DAQFactory - GoHighVoltage Computer Repair Forum

   View CSAF (https://github.com/cisagov/CSAF) 1. EXECUTIVE SUMMARY CVSS v4 8.4 ATTENTION: Low attack complexity Vendor: AzeoTech Equipment: DAQFactory Vulnerabilities: Out-of-bounds Write, Out-of-bounds Read, Access of Uninitialized Pointer, Heap-based Buffer Overflow, Type Confusion, Use...

   www.gohighvoltage.com
5. Related coverage: app.opencve.io
   
   

   Daqfactory CVEs and Security Vulnerabilities - OpenCVE

   Explore the latest vulnerabilities and security issues of Daqfactory in the CVE database

   app.opencve.io
6. Related coverage: manuallib.com
   
   

   1 Introducing DAQFactory

   PDF document

   www.manuallib.com