FactoryTalk Linx Privilege Escalation CVE-2025-9067/9068: Patch to 6.50

Rockwell Automation has published an urgent security advisory disclosing two high‑severity local privilege‑escalation flaws in FactoryTalk Linx that allow an authenticated Windows user to elevate to SYSTEM by abusing MSI “repair” behavior — vulnerabilities tracked as CVE‑2025‑9067 and CVE‑2025‑9068 — and the vendor’s fix is to move to FactoryTalk Linx 6.50 (or later) and apply a separate Microsoft MSI hardening patch where available.

Background / Overview​

FactoryTalk Linx is Rockwell Automation’s communications and driver platform used to bridge Logix controllers and higher‑level FactoryTalk or third‑party applications. It runs on Windows hosts in engineering, HMI, historian, and centralized integration environments where administrative and engineering activities occur. The newly disclosed issues affect FactoryTalk Linx versions 6.40 and earlier and were assigned CVE‑2025‑9067 and CVE‑2025‑9068; Rockwell’s advisory lists both as corrected in 6.50 and later.
Industrial control systems (ICS) and OT environments routinely mix Windows‑based engineering tools and privileged administrative workflows; that combination creates a high‑value target where local escalation can translate quickly into full operational compromise. Public reporting and community discussion of a related set of FactoryTalk advisories through 2024–2025 shows a pattern of high‑impact findings across multiple FactoryTalk components, reinforcing the operational urgency of patching these classes of flaws.

---

What exactly is broken? Technical summary​

The attack vector in plain terms​

Both flaws rely on the Microsoft Installer (MSI) repair mechanism that runs when an installed product is “repaired” by an authenticated user. During that repair flow the installer launches vendor-supplied helper processes (the MSI payloads used by FactoryTalk Linx), which on affected versions can be hijacked — the repair console window can be commandeered and then used to spawn a command prompt running under the SYSTEM account. The result is full local control over the host: access to all files, processes, and system resources.

• CVE‑2025‑9067 targets the x86 MSI component bundled with FactoryTalk Linx.
• CVE‑2025‑9068 targets the Rockwell Automation Driver Package x64 MSI repair functionality (specifically described by vendor writeups as enabling hijack of the vbpinstall.exe console).

Severity and scoring: CVSS v3.1 and v4​

Rockwell provides CVSS v3.1 base scores of 7.8 and CVSS v4 base scores of 8.5 for both CVEs; the CVSS v4 vectors emphasize local attack vectors with low attack complexity but major victim outcomes (high confidentiality, integrity, and availability impact). Independent vulnerability catalogs and trackers mirror these ratings and the vendor’s technical description.

Exploitability and scope​

• Access required: Authenticated local Windows user account with ability to run installer repair. The flaw is not described as remotely exploitable in its default configuration — an attacker must be local or have an account on the target host.
• Complexity: Low — the repair workflow is an intended feature and can be triggered by legitimate accounts, so an attacker who can start that flow can escalate.
• Impact: SYSTEM privileges on the host, enabling code execution, persistence, credential theft, lateral movement, or direct interference with ICS/OT workflows.

---

Why this matters to Windows and OT operators​

FactoryTalk Linx commonly runs on engineering workstations, HMI servers, or gateways that are both Windows machines and central orchestration points for automation stacks. Achieving SYSTEM on any such host is operationally catastrophic for several reasons:

• Control of engineering tools: With SYSTEM an attacker can read or modify controller projects, change setpoints, or corrupt firmware and logic files used to program PLCs.
• Lateral pivoting: Engineering hosts often have network access to controllers and other OT assets; a SYSTEM compromise enables credential harvesting and lateral movement.
• Safety and availability: Changes to control logic or disruption of HMI/SCADA services can produce physical safety incidents or prolonged production outages.

Community reporting and forum threads tracking recent FactoryTalk advisories show wide awareness among practitioners of escalating risk across FactoryTalk components, and operators should treat privilege‑escalation flaws as high priority even when they require local access.

---

Immediate vendor guidance and the official fix​

Rockwell’s advisory identifies the corrected code paths as present in FactoryTalk Linx 6.50 and later and lists SD1754 as the advisory. The vendor explicitly recommends upgrading to 6.50 where possible and also suggests applying Microsoft patches that harden MSI behavior as a complementary mitigation. Rockwell’s advisory indicates no KEV listing and shows the issue was found internally and responsibly disclosed.
Independent vulnerability databases (NVD, CVE aggregators) replicate the vendor’s summary and scoring details; NVD entries for these CVEs are present but may be marked “awaiting analysis” while vendor data feeds populate. Cross‑checking these sources confirms the affected versions (6.40 and prior) and remediation guidance (upgrade to 6.50+).

---

Practical mitigation checklist — prioritized, actionable steps​

Operators must balance urgency with operational safety in ICS environments. The numbered plan below reflects defensible priorities and step sequencing for teams managing FactoryTalk Linx hosts.

• Inventory and prioritize
• Identify all hosts running FactoryTalk Linx v6.40 or earlier (engineering workstations, HMI/VM hosts, license servers).
• Prioritize hosts that are internet‑exposed, domain‑joined, or hold engineering artifacts (project files, credentials).
• Patch and upgrade (primary remediation)
• Schedule and plan an upgrade to FactoryTalk Linx 6.50 or later in a test environment first; validate integrations (RTUs, historians, Studio 5000).
• After testing, deploy 6.50 in controlled maintenance windows, following change‑control.
• Apply Microsoft MSI hardening patch (if available)
• Rockwell recommends applying the Microsoft patch addressing MSI repair‑related risks where applicable — consult your Microsoft patching channels and test the patch prior to production deployment.
• Where immediate upgrade is not possible — apply compensating controls
• Restrict who can initiate MSI repairs: limit membership of the local Administrators group and ensure only trusted administrators have installer privileges.
• Enforce least privilege for interactive logons on engineering hosts; use separate hardened jump boxes for administration.
• Implement application allowlisting (AppLocker or third‑party) to block unexpected msiexec or vbpinstall.exe child processes.
• Disable or restrict Windows Installer service where possible, or block interactive repair via Group Policy if compatible with operational needs.
• Hardening and monitoring
• Enable detailed Windows auditing for process creation and privilege escalation events; watch for suspicious msiexec, vbpinstall.exe, or unexpected cmd.exe spawned by installer processes.
• Create SIEM/EDR detection rules for: msiexec starting vbpinstall.exe; vbpinstall.exe spawning cmd.exe; cmd.exe running under LocalSystem where the parent process is an MSI installer.
• Use host‑based EDR to quarantine and record suspicious process trees and to block unauthorized privilege escalation attempts.
• Control access and segmentation
• Ensure engineering hosts and FactoryTalk servers are on segmented, firewalled subnets. Use strict ACLs to prevent non‑engineer workstations from reaching engineering servers.
• Require multifactor authentication for accounts with install/repair privileges where possible.
• Incident readiness
• Prepare runbooks that include isolating compromised hosts, collecting volatile evidence (memory, process lists), and restoring from known‑good images.
• If compromise is suspected, prioritize offline verification of project integrity and credential rotation for accounts used on affected hosts.

These steps align with Rockwell’s remediation guidance and standard ICS defense‑in‑depth practices.

---

Detection: what to look for in logging and telemetry​

Detecting local privilege escalation post‑factum requires foresight in logging and telemetry. Key signals to instrument and monitor:

• Process parent/child anomalies: msiexec.exe (or other installer processes) creating long‑running console windows or spawning cmd.exe, powershell.exe, or unusual service installers (e.g., vbpinstall.exe).
• Unexpected SYSTEM processes: shell processes showing LocalSystem as their token where the parent is an installer.
• Windows Event Logs: Event IDs for process creation (Sysmon Event ID 1 if Sysmon is deployed), Service Control Manager events for unexpected service installs, and Security logs for privilege use.
• EDR alerts: anomalous DLL load chains originating from installer processes, persistence mechanisms created shortly after an installer run.
• File system changes: modifications to Program Files, Windows\Installer, or Registry keys commonly touched by installers during repair flows.

Create detections tailored to the specific installer filenames and tools used by FactoryTalk Linx in your environment (for example, watch for vbpinstall.exe behavior). Audit rules and EDR signatures tuned to these behaviors will accelerate detection and containment.

---

Operational considerations and change control in OT contexts​

Patching OT systems is operationally risky — an ill‑timed update can disrupt production. Apply these operational best practices:

• Always test the upgrade in an isolated lab that mirrors production engineering stacks, including Studio 5000 versions, OPC servers, and historian integrations.
• Coordinate patch windows with operations/safety teams; document rollback plans and ensure backups of controller projects and configuration snapshots before upgrade.
• Use staged rollouts: update non‑critical engineering hosts first, then move to HMI/SCADA servers, and finally to any production‑adjacent hosts.
• Communicate change windows to contractors and third parties who may have engineering access.
• Validate that license activation and driver compatibility are intact after upgrade to 6.50; some driver packages may require a reinstallation or vendor driver updates.

---

Risk assessment: strengths, unknowns, and residual exposure​

Notable strengths of the vendor response​

• Timely disclosure and patch: Rockwell published SD1754 with specific CVE assignments and a corrective version (6.50), which enables coordinated patching across customers.
• Clear technical description: The advisory explains the attack vector (MSI repair hijack) in practical terms, allowing defenders to create targeted detections and mitigations.

Remaining risks and caveats​

• Local‑only access requirement: Although the flaws are not remotely exploitable by default, many environments expose engineering hosts via VPN, RDP, or shared credentials; attackers can exploit lateral access to reach a host and then use these flaws. Treat “local” as an operational boundary that can be crossed.
• Unverified public exploitation: As of the vendor advisory publication, there are no confirmed public exploit reports, but the attack is simple enough that proof‑of‑concepts could appear quickly. Organizations should act under the assumption that exploit code could be developed and shared. Flag or note any public exploit claims for validation.
• Residual exposure for legacy systems: Many industrial sites run long‑inherited images and older FactoryTalk stacks where applying 6.50 quickly is operationally infeasible; these environments require layered compensating controls (network isolation, strict account management, allowlisting).

---

Detection, response, and post‑incident steps (detailed)​

If you suspect exploitation or anomalous installer behavior:

• Immediately isolate the host from OT and business networks; preserve forensic images and volatile memory snapshots.
• Collect EDR and Sysmon logs, and capture the process tree for msiexec/vbpinstall.exe and any spawned cmd.exe/powershell.exe instances.
• Rotate credentials used on the host and any service accounts that may have been accessed, and reset passwords for domain accounts that logged into the host.
• Inspect controller project files, backup archives, and HMI configurations for unauthorized changes or new artifacts.
• Engage ICS incident response specialists if control logic or physical processes could have been altered. Prepare to restore from verified backups where appropriate.
• Notify necessary stakeholders, including vendor PSIRT if the compromise appears to involve product vulnerabilities.

---

Broader lessons for ICS/Windows convergence​

• Installer flows are attack surfaces: System installation and repair mechanisms are designed to run with elevated privileges — that makes them target‑rich for privilege‑escalation attacks. Treat any automatic or repair installer flow with caution, and restrict who can invoke them.
• Defense‑in‑depth matters: Local‑only vulnerabilities are still critical in environments where remote access or weak account hygiene is present. Network segmentation, strict privilege controls, and application allowlisting remain foundational mitigations.
• Inventory and visibility: Knowing which hosts run vendor packages such as FactoryTalk Linx, and mapping where those hosts connect, is a prerequisite for effective risk reduction.
• Coordinated disclosure works: Rockwell’s disclosure and CVE assignments let customers and agencies coordinate defensive action; organizations should participate in vendor‑driven patch cycles and follow CISA guidance for ICS resilience.

---

Conclusion​

CVE‑2025‑9067 and CVE‑2025‑9068 are high‑impact local privilege‑escalation vulnerabilities in FactoryTalk Linx that transform an authenticated user foothold into full SYSTEM control by abusing MSI repair behavior. Vendor guidance is unambiguous: plan and test an upgrade to FactoryTalk Linx 6.50 or later, apply Microsoft MSI hardening patches where appropriate, and implement compensating controls in cases where immediate patching is operationally impossible. Operational teams must prioritize inventory, testing, and staged deployment, while security teams should tune EDR/SIEM rules to detect installer‑hijack behaviors and prepare incident response playbooks for rapid containment.
Community discussion and prior advisories for FactoryTalk components highlight a consistent operational lesson: ICS operators cannot rely on “not remotely exploitable” as comfort — local attack paths are realistic in modern, connected environments, and the combination of Windows engineering hosts plus ICS integration multiplies the consequences of local privilege escalation. Apply the vendor fixes, harden installer flows, and assume commodity exploit code may appear quickly.

---

---

Source: CISA Rockwell Automation FactoryTalk Linx | CISA