Nine high-severity remote code execution (RCE) vulnerabilities in INVT’s HMITool and VT-Designer engineering software are exposing Windows workstations in industrial environments to attacks through malicious project files, with no vendor patches currently available. The Zero Day Initiative (ZDI) published advisories for the flaws on July 7, 2025, after months of unsuccessful coordination with INVT, leaving defenders with only mitigation measures until fixes arrive. The vulnerabilities—tracked from CVE-2025-7223 to CVE-2025-7231—affect HMITool version 7.1.011 and VT-Designer version 2.1.13, two widely used tools for programming and monitoring industrial control systems. They stem from memory corruption bugs in the parsing of VPM and PM3 project files, allowing an attacker who tricks a user into opening a crafted file to execute arbitrary code with the privileges of the application.

The Flaws at a Glance

The advisory package splits the nine CVEs across the two products:
- HMITool 7.1.011: CVE-2025-7223, CVE-2025-7224, CVE-2025-7225, CVE-2025-7226—all out-of-bounds write (CWE-787) issues in the VPM file parser.
- VT-Designer 2.1.13: CVE-2025-7227, CVE-2025-7228, CVE-2025-7229, CVE-2025-7230, CVE-2025-7231—a mix of out-of-bounds write and a type confusion (CWE-843) flaw in the PM3 file parser.

Each vulnerability carries a CVSS v3.1 base score of 7.8, indicating a locally exploitable, high-impact bug that requires user interaction. ZDI’s advisories emphasize that exploitation is possible only when a victim opens a specially crafted file, but in real-world industrial workflows—where engineers routinely exchange project files via email, USB drives, or network shares—this prerequisite is trivially met.

A Deep Dive into the Vulnerabilities

Out-of-Bounds Write Mayhem

The core of most of these bugs is a failure to validate user-supplied data during file parsing. When HMITool or VT-Designer loads a VPM or PM3 file, parser routines trust length or count fields embedded in the file. By manipulating those fields, an attacker can force the application to write data past the end of an allocated buffer, corrupting adjacent memory. Such out-of-bounds writes are classic primitives for hijacking program control flow—overwriting function pointers, exception handlers, or other critical structures—leading to reliable code execution.

ZDI’s advisory for CVE-2025-7223 (HMITool) describes the root cause bluntly: “The specific flaw exists within the parsing of VPM files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer.” The identical language appears for the other out-of-bounds CVEs, suggesting a systemic lack of input sanitization across both file formats.

Type Confusion in VT-Designer

At least one CVE (CVE-2025-7230) introduces a type confusion vulnerability in the PM3 parser. Here, the software interprets a piece of data as one type (e.g., an integer) when the attacker has provided a different type (e.g., a pointer), causing the program to perform an unsafe operation. This can corrupt object layouts, bypass security checks, or directly alter execution flow. Type confusion bugs are notoriously tricky to spot and often yield powerful exploit primitives.

The Windows Industrial Workstation: A Prime Target

HMITool and VT-Designer run on standard Windows machines that double as engineering stations and operator interfaces. These workstations sit at the intersection of IT and OT networks—often with direct connectivity to programmable logic controllers (PLCs), human-machine interfaces (HMIs), and engineering repositories. A successful compromise therefore extends far beyond a single desktop: an attacker can pivot into the industrial control network, modify logic on controllers, manipulate operator displays, or sabotage physical processes.

Windows administrators managing these environments face a delicate balancing act. The applications are trusted and often require elevated privileges, yet they are exposed to the same file-borne threats as any desktop software. Traditional defenses like antivirus may not flag custom project files, and patching cycles in OT systems are notoriously slow. The result is a high-value, soft target.

The impact is magnified by typical user behavior. Engineers regularly open project files from vendors, integrators, or colleagues without a second thought. An attacker can weaponize a PM3 or VPM file and deliver it via a spear-phishing email, a compromised shared folder, or a malicious website. ZDI’s advisory explicitly notes that the target “must visit a malicious page or open a malicious file,” a scenario that aligns perfectly with everyday engineering workflows.

Disclosure Timeline: Vendor Silence Forced Zero-Day Release

ZDI’s detailed timeline for CVE-2025-7223 reveals a frustrating coordination process:
- August 15, 2024: ZDI requested the vendor’s PSIRT contacts via email to the support team.
- November 13, 2024: ZDI asked for updates.
- March 11, 2025: ZDI submitted the report to ICS-CERT.
- May 14, 2025: ZDI asked for updates again; ICS-CERT tried multiple channels to reach the vendor through June 24, 2025.
- July 7, 2025: With no patch forthcoming, ZDI published the advisory as a zero-day.

The timeline indicates that INVT was unresponsive for nearly a year, leaving critical infrastructure users in the dark. ICS-CERT’s involvement, while helpful, did not accelerate a fix. The same pattern likely applies to the VT-Designer flaws disclosed the same day. This breakdown in collaboration places the onus entirely on defenders to implement compensating controls.

Immediate Mitigations for Windows Administrators

Until INVT releases validated patches, the only effective defense is to reduce the attack surface and harden affected systems. The following steps are drawn from ZDI’s guidance, CISA’s weekly vulnerability summaries, and practical ICS security best practices.

Step 1: Isolate and Segment

Cut off Internet access. Ensure that no engineering workstation running HMITool or VT-Designer accepts inbound connections from the internet. Use host-based firewalls and network access control lists to restrict traffic to only essential OT protocols. Segment the engineering VLAN from business networks and remote access gateways—a compromise in the corporate zone should not easily reach these machines.

Step 2: Harden the Operating System

  • Run with least privilege. Remove local administrator rights from user accounts that operate the engineering software. If the applications require elevation for certain tasks, use temporary privilege escalation methods rather than leaving users as admins permanently.
  • Enable application allowlisting. Use Windows AppLocker or third‑party tools to create rules that permit only signed, trusted executables to run, including the INVT software. This restricts the attacker’s ability to launch secondary payloads even if they achieve code execution.
  • Deploy exploit mitigation features. Enable Windows Defender Exploit Guard, which includes arbitrary code guard, control flow guard, and other mitigations that can break common exploitation techniques. While not foolproof, these raise the bar considerably.
  • Keep EDR and antivirus up to date. Trend Micro and other vendors have released virtual‑patch signatures that detect exploit attempts targeting these CVEs. Apply the latest definitions and enable behavioral monitoring that flags anomalous process behavior from designer/HMI processes.

Step 3: Control File Handling

  • Treat all incoming PM3/VPM files as untrusted. Configure mail gateways to quarantine attachments with these extensions unless from a verified sender. Block these file types on file-sharing services and disable autorun for USB storage.
  • Designate a jump host for file inspection. Create an isolated virtual machine (VM) that has no access to control networks and use it to open and scan project files received from third parties. Only after verification should the file be moved to the production engineering workstation.
  • Monitor file access. Set up SIEM alerts for any user opening a PM3 or VPM file outside of known, approved directories or at unusual times. Strange file-open events are often the first sign of a social‑engineering attack.

Detection and Incident Response

Exploitation of memory corruption bugs often leaves telltale signs on the Windows host. Defenders should hunt for:
- Application crashes or unexpected restarts of VT-Designer or HMITool.
- Child processes spawned by the engineering software that are atypical—e.g., cmd.exe, powershell.exe, or msiexec.exe appearing as a child of the designer executable.
- Network connections from the workstation to unknown external IP addresses shortly after a project file is opened.
- Unsigned DLLs loaded into the application’s memory space.

If any of these indicators fire, isolate the endpoint immediately, preserve volatile memory (with a tool like WinPMem), collect Windows event logs, and perform an offline integrity check of recently opened project files. Compare running PLC and HMI programs against known‑good golden copies to detect unauthorized changes.

Long-Term Resilience

Beyond the immediate patch cycle, industrial organizations must accept that engineering tools are a permanent part of the attack surface and plan accordingly:
- Move to immutable engineering VMs. Build a clean, up‑to‑date virtual machine image with only the necessary software; re‑image it after each use or at least weekly. This limits the opportunity for malware to persist.
- Enforce version control and change management for all PLC/HMI code. Every authorized change should be traceable; any unauthorized change should trigger an immediate investigation. This makes it harder for an attacker to silently manipulate physical processes.
- Apply multi‑factor authentication to jump hosts used for remote maintenance. Even if an engineering workstation is owned, lateral movement into the OT environment should require a second factor that the attacker doesn’t have.
- Conduct regular security reviews of OT‑adjacent Windows systems. Ensure that patch management, endpoint protection, and monitoring are held to the same standard as business‑critical servers.

The Bottom Line

INVT’s silence on these nine RCE flaws leaves a glaring hole in the defenses of countless industrial sites that rely on HMITool and VT-Designer. Windows administrators must act now—not when a patch finally arrives—to isolate vulnerable workstations, harden the OS, and control the flow of project files. The ZDI advisories, NVD entries, and CISA’s recognition of these CVEs provide the authoritative technical details; the operational urgency comes from the reality that engineering files are exchanged daily with little scrutiny. This incident should also serve as a wake‑up call for the ICS vendor community: timely vulnerability response is not optional when the products control the machinery that keeps the lights on. Defenders, meanwhile, can treat this as a drill for the next inevitable disclosure — the playbook of isolation, hardening, and detection scales to any file‑parsing RCE in an engineering tool.