Rockwell Automation has shipped FactoryTalk Linx version 6.50 to close two high-severity local privilege escalation vulnerabilities that turn a legitimate Windows installer repair into a full system takeover. The flaws, designated CVE-2025-9067 and CVE-2025-9068, affect FactoryTalk Linx 6.40 and earlier and were publicly disclosed on October 15, 2025, through a CISA advisory. An attacker who already has authenticated access to an engineering workstation can trigger an MSI repair, hijack the resulting console window, and launch a command prompt with SYSTEM privileges—effectively owning the host and everything it connects to.
Rockwell’s internal discovery and coordinated disclosure gave operators a clear path: upgrade to 6.50 (or later) and apply the complementary Microsoft MSI hardening patch where available. For the thousands of plants running FactoryTalk Linx as the communications bridge between Windows tools and Logix controllers, these bugs are a reminder that local attack vectors are far from benign when one foothold can cascade into operational compromise.
The Twin Flaws: MSI Repair Turns into a SYSTEM Shell
Both vulnerabilities hinge on a long-understood but frequently overlooked behavior of the Microsoft Installer: repair operations run with elevated privileges and can launch vendor-supplied executable tasks that inherit that power. An authenticated user with the ability to start a repair—something many domain accounts can do—can manipulate the console window of those launched processes and spawn a shell as LocalSystem.
CVE-2025-9067 targets the x86 MSI component bundled with FactoryTalk Linx. During a repair, the installer executes one of the platform’s helper programs inside a console window. By hijacking that window (for instance, by sending keystrokes or interrupting the flow), the attacker gains a command prompt running under SYSTEM. The second flaw, CVE-2025-9068, is identical in technique but exploits the Rockwell Automation Driver Package x64 MSI repair. The specific console window that gets hijacked belongs to vbpinstall.exe, a driver installation utility that also runs with full system rights when launched from the MSI repair.
Both CVEs carry a CVSS v3.1 base score of 7.8 and a CVSS v4 base score of 8.5, reflecting low attack complexity, local access, and high impact on confidentiality, integrity, and availability. The CISA advisory and Rockwell’s own notice (SD1754) are unambiguous: the attack requires no special tools, no memory corruption, and no elevated starting privileges—only a valid Windows account and the ability to trigger a repair.
When an Engineering Workstation Falls: Operational Impact
FactoryTalk Linx isn’t an obscure utility. It runs on engineering workstations, HMI servers, historians, and centralized gateways where it translates communication between Rockwell controllers, Studio 5000, and third-party applications. In many facilities, those same Windows hosts sit on the same network segment as programmable logic controllers (PLCs) that drive physical machinery.
Gaining SYSTEM on such a host means:
- Controller compromise: The attacker can read, modify, or replace PLC logic, setpoints, and firmware from the engineering tools already accessible on the machine.
- Lateral movement: Engineering credentials, VPN configurations, and stored network maps are often cached on these systems, enabling a pivot to other OT and IT assets.
- Production shutdown or unsafe conditions: Disrupting HMI services or altering safety logic can lead to downtime or physical harm.
The local-only prerequisite doesn’t diminish the risk. Modern industrial environments regularly expose engineering workstations through remote desktop, VPNs, or misconfigured jump hosts. A phishing email that lands an attacker a low-privilege domain account on a factory floor PC can quickly become a SYSTEM shell on the engineering server next door.
A Pattern of FactoryTalk Hardening
This isn’t the first time the FactoryTalk ecosystem has needed patching for high-impact local issues. Throughout 2024 and early 2025, a string of advisories addressed privilege escalation, denial-of-service, and information disclosure flaws in components like FactoryTalk View, AssetCentre, and Services Platform. The common thread: Windows installer and service architectures that trust local accounts more than they should.
Rockwell’s disclosure for these latest CVEs came through CISA’s ICS advisory pipeline, meaning the vendor internally found the bugs and opted for a coordinated fix. While no public exploit code has surfaced, the attack mechanism is simple enough that a proof-of-concept could appear within weeks. The industrial security community has long warned that installer repair paths are a soft underbelly in OT environments, and these CVEs add concrete examples to that argument.
Patching and Defending: The Upgrade to 6.50
The primary remediation is straightforward: upgrade FactoryTalk Linx to version 6.50 or later, where the affected MSI payloads have been corrected. Rockwell also recommends installing any available Microsoft patch that hardens MSI repair behavior (referenced in the advisory as an complementary measure). For sites running 6.40 and earlier, the recommended sequence is:
- Inventory and test: Identify every Windows host running FactoryTalk Linx 6.40 or prior—including engineering laptops, VMs, and license servers. Spin up a lab with a mirror of your production stack and validate the 6.50 upgrade against all dependent software (Studio 5000 versions, OPC servers, historians).
- Staged rollout: Deploy the upgrade during a planned maintenance window, starting with non-critical engineering hosts, then moving to HMI servers, and finally any production-adjacent gateways. Ensure rollback media and controller project backups are available.
- Apply Microsoft MSI hardening: Check your Windows update channel for patches that restrict elevated console hijacks during repairs. Test the patch in your lab first—it may alter the behavior of other installed products that rely on similar repair flows.
If You Can’t Upgrade Immediately
Many OT environments run legacy images or have validation windows that stretch for months. For those teams, Rockwell’s advisory and industry best practices offer a layered set of compensating controls:
- Restrict repair privileges: Remove standard users from the local Administrators group on all FactoryTalk hosts. Use Group Policy to block interactive “repair” operations for the FactoryTalk Linx MSI packages (the product code can be found in the registry or through event logs).
- Application allowlisting: Deploy AppLocker or Windows Defender Application Control to prevent unexpected msiexec.exe child processes, especially vbpinstall.exe and cmd.exe, from launching outside approved directories.
- Network segmentation: Isolate engineering workstations from business networks and from each other except where necessary. Use strict firewall ACLs so that only authorized management machines can reach the hosts that run FactoryTalk Linx.
- Logging and detection: Enable process creation auditing (Sysmon Event ID 1 or Windows Security Event ID 4688) and create alerts for msiexec.exe spawning vbpinstall.exe, or any SYSTEM shell that has an MSI installer as its parent. Send logs to a SIEM that can correlate these signals with other signs of intrusion.
Beyond the Patch: Detection and Resilience
Even with the upgrade, assume that a determined attacker may find another elevation path. Detection engineering should focus on the specific process trees these CVEs exploit:
- Parent–child anomalies: Watch for msiexec.exe launching vbpinstall.exe, and vbpinstall.exe in turn spawning cmd.exe, powershell.exe, or other interactive shells.
- Token inspection: Any shell running as LocalSystem (NT AUTHORITY\SYSTEM) where the parent is an installer process is a red flag.
- File system changes: Monitor the Windows\Installer directory and Program Files\Rockwell for unexpected modifications during non-maintenance periods.
If exploitation is suspected, isolate the host immediately, capture volatile data (memory, process lists), rotate all credentials used on the machine, and verify the integrity of controller projects and HMI screens. The operational loss from a SYSTEM-level breach on an engineering workstation is high enough that many teams are preparing incident response playbooks specifically for installer-hijack scenarios.
While the immediate fix is a single version upgrade, CVE-2025-9067 and CVE-2025-9068 underscore a broader lesson: Windows installer repair mechanisms are a built-in escalation path that OT environments haven’t always included in their threat models. As Rockwell and other ICS vendors continue to harden their installers, Microsoft’s own efforts to lock down elevated repair processes will become a critical second layer. For now, the 6.50 upgrade is the fastest way to shut the door before exploit code arrives.