AzeoTech’s DAQFactory has been the subject of a high‑severity industrial control systems (ICS) advisory: multiple memory‑safety and parsing flaws in DAQFactory Release 20.7 (Build 2555) and earlier can be triggered by specially crafted project files (.ctl), and the vendor has released a corrected build (DAQFactory Release 21.1) to address the issues. The advisory lists a compact but dangerous attack model — a user or service opens an attacker‑controlled .ctl file and, because of out‑of‑bounds reads/writes, use‑after‑free, uninitialized pointer access, and both heap and stack buffer overflows, memory corruption can occur that may permit information disclosure or arbitrary code execution in the context of the DAQFactory process. The advisory includes several CVE identifiers and CVSS v3/v4 scores; operators should treat the vendor update and CISA’s recommended mitigations as a top priority.
Overview
DAQFactory is a widely used data‑acquisition, HMI and application development platform that runs on Windows engineering workstations and industrial PCs. It is commonly used in critical manufacturing, energy and water/wastewater environments, where engineering workstations that host DAQFactory are trusted with configuration files, scripts, and project deployments. The vendor maintains documentation and upgrade guidance on its site. This advisory is notable for three reasons:
- The attack vector is local file parsing: specially crafted .ctl files (project files) are the delivery mechanism; this makes the flaws file‑based rather than directly network wormable, but still significant because engineering documents are frequently exchanged across teams and contractors.
- The vulnerability classes combine multiple classic memory‑corruption patterns (out‑of‑bounds read/write, use‑after‑free, type confusion, uninitialized pointer, heap/stack buffer overflows), which increase the difficulty of reliably assessing impact and exploitation complexity but raise the potential for full RCE if chained or exploited in permissive environments.
- The vendor has published a remediation release (DAQFactory Release 21.1) that the advisory identifies as the fix; operators should plan to validate and deploy this release following normal change‑control and test procedures.
Background and context
What is DAQFactory and where it’s used
DAQFactory is an engineering/HMI/SCADA toolkit designed to collect data, script logic, and build operator displays. It is typically run on Windows engineering workstations and on HMIs in industrial environments. The product line is actively maintained by AzeoTech and includes documentation and download pages for releases.
Why project‑file parsing vulnerabilities are dangerous in ICS
Engineering files (project files, configuration bundles, .ctl documents) are both a threat vector and a necessity in OT workflows. They routinely contain serialized internal state, scripts, GUI definitions and references to device configuration. If a product deserializes or parses those files with insufficient bounds checks or unsafe memory handling, attackers can weaponize an otherwise innocuous document to compromise the host engineer’s machine — and from there pivot to controllers, HMIs, or other OT assets. This advisory falls squarely into that category: the attack begins with a crafted .ctl file and requires the file to be opened by a DAQFactory instance.
Technical summary of the findings
The advisory enumerates multiple weakness types present in DAQFactory Release 20.7 (Build 2555) and earlier. Key technical facts reported in the advisory:
- Vulnerability families: Out‑of‑bounds write, Out‑of‑bounds read, Access of uninitialized pointer, Heap‑based buffer overflow, Type confusion, Use after free, Stack‑based buffer overflow. Each of these can lead to memory corruption and — if exploited — to arbitrary code execution or information disclosure.
- Assigned CVEs: The advisory lists a set of CVE identifiers associated with the different memory‑safety issues (for example CVE‑2025‑66590 through CVE‑2025‑66584). The advisory provides CVSS v3.1 and CVSS v4 base scores (many in the high‑7 to high‑8 range, and a CVSS v4 8.4 cited for some memory‑safety items). Organizations should treat those scores as guidance and evaluate them against their own risk profiles (exposure, compensating controls, and exploitability in their environment).
- Attack model / preconditions: The programmatic precondition described is simple — the user or an automated process must load/open a crafted .ctl file. In many ICS workflows, project files are exchanged with vendors, contractors, or external parties; that exchange model makes targeted attacks realistic even without direct network access.
- Scope: DAQFactory Release 20.7 (Build 2555) and prior are called out as affected; the advisory recommends updating to Release 21.1 where the issues are addressed.
Verification and cross‑checks
- The DAQFactory user manual and vendor pages confirm DAQFactory’s role as a Windows‑based HMI/DAQ platform and provide general upgrade instructions for moving between releases — helpful for planning a test/upgrade path. Operators should follow vendor guidance for obtaining and validating the 21.1 release.
- AzeoTech and CISA have a history of coordinated advisories for DAQFactory (prior advisories from 2011, 2014, 2017 and 2021 show that DAQFactory has previously required mitigations and new releases to address security problems). This historical record reinforces that engineering tools parsing project files need special handling in ICS environments.
- NOTE ON CVE/DB VERIFICATION: the advisory itself lists CVE identifiers and CVSS vectors. Public vulnerability repositories (CVE/NVD/MITRE) sometimes lag or enrich at different times; defenses and patching schedules must rely first on the vendor/CISA advisory and validated vendor releases. Where public CVE pages were not authoritative at the time of checking, treat the advisory’s CVE assignments as the canonical source until national trackers produce consolidated records. This is a common pattern with coordinated disclosures and does not reduce the practical urgency of patching.
Practical impact and risk evaluation
What an attacker can do
- If the memory corruption leads to code‑execution primitives on the host running DAQFactory, an attacker could run arbitrary code at the privilege level of the DAQFactory process. On Windows engineering workstations, that process often runs as an interactive user who may have access to OT configuration, project repositories and remote maintenance tools. That access can be converted into:
- Credential theft (project credentials, saved connections).
- Lateral movement to engineering servers, jump boxes, or directly to field devices (if the workstation is a trusted bridge).
- Plant‑level manipulation if attacker can modify project contents pushed to controllers.
Preconditions that reduce broad exploitation
- The primary vector requires opening a malicious .ctl file; the vulnerability is not described as remotely exploitable without user action (i.e., it’s not a network worm by itself). However, social engineering, shared project repositories, contractor supply chains, or malicious USB/SMB drops make targeted exploitation realistic.
Relative severity
- The advisory’s CVSS v3 and v4 scores are high because the impact (confidentiality/integrity/availability) is high if exploitation succeeds. The attack complexity measure is often low in these advisory calculations when the file format parsing can be triggered reliably by a crafted document and the target opens it. However, practical exploit reliability can be affected by modern OS exploit mitigations (ASLR, DEP/NX, CFG) and patching/AV/EDR presence on the host.
Immediate mitigations (prioritized)
- Apply the patch: Upgrade to DAQFactory Release 21.1 in a controlled test environment, validate with your project files and scripts, then schedule a production rollout. The vendor release is the authoritative fix for the issues reported in the advisory.
- Block and isolate engineering workstations:
- Ensure engineering systems running DAQFactory are on segmented, isolated networks that are not reachable from the public internet or general corporate user networks.
- Use strict firewall rules and access control lists that permit only known management hosts and jump servers to connect to engineering workstations. This is standard ICS defense guidance.
- Lock down .ctl files:
- Store .ctl files in directories writable only by admin‑level or designated engineering accounts.
- Where possible, implement document signing, checksums, or other integrity checks so the system only opens signed/trusted project files.
- Enforce “safe mode” or an equivalent restricted parsing mode for opening files from untrusted sources. The advisory suggests operating DAQFactory in Safe Mode for documents outside your control.
- Reduce user attack surface:
- Train engineers to treat inbound project files from third parties as untrusted until validated.
- Block the use of removable media where feasible or ensure removable media is scanned and quarantined before use on engineering hosts.
- Endpoint defenses and detection:
- Ensure EDR is running on engineering hosts, with rules to detect unusual process behavior (process injections, new service creation, unexpected child processes launched by DAQFactory).
- Enable host logging (process creation, file writes, scripting engine usage) and centralize logs for rapid triage.
- Compensating controls when patching is delayed:
- If you cannot immediately upgrade, restrict file‑opening privileges (only allow specific users to open .ctl files), and implement application whitelisting to constrain what a compromised process can execute.
- Consider running DAQFactory sessions inside hardened virtual machines or isolated jump hosts dedicated to interpreting third‑party files.
Detection and incident response guidance
- High‑value signals to monitor:
- Unexpected crashes or repeated process exceptions in DAQFactory after opening external files.
- DAQFactory spawning unusual child processes (cmd.exe, powershell.exe, wscript/cscript, or any remote execution tooling).
- Unexpected network connections from engineering workstations to untrusted destinations following file loads.
- Sudden changes to project file repositories, new or modified .ctl files with timestamps inconsistent with expected workflows.
- Response steps for suspected exploitation:
- Isolate the affected host from the network (segmented offline quarantine).
- Preserve volatile forensic evidence (memory image if feasible), and collect DAQFactory logs, recent .ctl files and process creation logs.
- Restore from a known good backup after reimaging, rather than attempting to repair an unknown memory‑corruption compromise in place.
- Rotate credentials and secrets that may have been accessible from the compromised workstation.
- Report incidents according to regulatory requirements and coordinate with your vendor and national CSIRT (if applicable).
Detection playbook (practical items for Windows admins)
- EDR rule examples to consider (implement carefully in testing):
- Alert on DAQFactory.exe executing cmd.exe/powershell.exe/wscript.exe/cscript.exe.
- Alert on DAQFactory.exe performing unexpected memory allocation patterns or heap manipulations (EDR heuristics).
- Block DAQFactory from launching untrusted installers or dropping executables into system folders via AppLocker/WDAC policies where feasible.
- File integrity checks:
- Maintain hash whitelists for approved .ctl files used in production.
- Use a quarantined sandbox to open and validate third‑party project files before promotion into the production environment.
Critical analysis and commentary
Strengths of the advisory and vendor response
- The advisory is specific about the affected release (20.7 build 2555 and prior) and the attack vector (.ctl file parsing), which makes targeted mitigation feasible.
- The vendor’s patch release (21.1) provides a canonical remediation path — organizations can test and roll forward with confidence once upgrades are validated.
- CISA’s standard ICS guidance (segment, firewall, restrict network exposure, secure remote access) aligns with industry best practice and is practical to implement in most environments.
Risks and gaps
- The attack model’s reliance on user interaction can create a false sense of safety. In operational environments where third parties share projects routinely — contractors, vendors, OEMs — the file exchange channel is a real and persistent risk. A seemingly benign supply‑chain movement of project files can create an attack path.
- Memory‑safety issues listed (use‑after‑free, type confusion, uninitialized pointer) are the kind of bugs that can be hard to fully mitigate in legacy code without significant code changes. While the released patch likely addresses the immediate parsing failures, defenders should treat the product as higher risk and continue to monitor for follow‑on advisories or further disclosure.
- Public CVE and NVD records may lag vendor/CISA advisories or not yet reflect the computed CVSS v4 vectors; organizations should not wait for third‑party databases to take action when the vendor and national authority have published guidance.
Threat likelihood
- No confirmed in‑the‑wild exploitation was reported at the time of the advisory’s publication, but the combination of high impact and the relatively low barrier (convincing an engineer to open a file) places this in the “high potential” bucket for targeted attacks against industrial facilities. Given past patterns in ICS targeting, any memory‑corruption flaw in engineering software should be prioritized for remediation.
Checklist for Windows engineers and SOC teams
- Inventory all DAQFactory installations and record release/build numbers.
- If any host runs 20.7 (Build 2555) or earlier, plan immediate remediation:
- Test DAQFactory Release 21.1 in a staging environment.
- Validate all production projects and scripts under 21.1 before deployment.
- Implement the file handling hardening:
- Restrict .ctl file write locations to admin‑writable directories.
- Use checksums or signing for production project bundles.
- Harden endpoints:
- Enforce EDR with appropriate policies and monitor the detection signals listed earlier.
- Apply application whitelisting and least privilege.
- Network controls:
- Segment and isolate engineering networks from business networks.
- Use jump hosts for external connections and maintain updated VPN gateways for remote maintenance.
- Training and policy:
- Update change management and third‑party file handling policies.
- Train contractors and vendors on secure file sharing protocols for project files.
Final takeaways
- The DAQFactory advisory identifies classic, high‑impact memory‑corruption issues in a widely used engineering product; the real‑world risk comes from the trusted nature of engineering project files and the privileged position of engineering workstations.
- The vendor released DAQFactory Release 21.1 to address the problems cited in the advisory; migrating to the patched release after testing should be the top operational priority.
- While the flaws require the malicious file to be opened, that single step is common in modern OT workflows; therefore, patching, file governance, segmentation, endpoint detection, and disciplined supply‑chain policies are necessary to reduce both the chance and impact of exploitation.
Operators running DAQFactory on Windows engineering systems should treat this advisory as high priority: confirm your installed release, schedule a test and upgrade to Release 21.1 as soon as possible, and apply the network and host mitigations outlined above while you complete the upgrade and verification process.
Source: CISA
AzeoTech DAQFactory | CISA