Industrial control system operators running Rockwell Automation’s FactoryTalk Optix visualization platform face a critical threat: a flaw in the product’s embedded MQTT broker allows unauthenticated remote attackers to load malicious plugins and execute arbitrary code on the host. Assigned CVE-2025-9161 with a CVSS v4 base score of 7.3, the vulnerability affects FactoryTalk Optix versions 1.5.0 through 1.5.7. Rockwell’s recommended remediation is an immediate upgrade to version 1.6.0 or later. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) republished the advisory on July 23, 2025, amplifying its urgency for critical infrastructure operators.

What Is FactoryTalk Optix?

FactoryTalk Optix is a modern, cloud-enabled visualization platform in Rockwell Automation’s FactoryTalk family, designed for HMI/SCADA dashboards, distributed operator interfaces, and telemetry forwarding. The product integrates an MQTT broker — historically based on Eclipse Mosquitto — to provide lightweight publish/subscribe messaging for eventing, alarms, and data analytics. This broker’s flexible URI scheme, meant to support remote plugin loading, is the attack vector.

The Vulnerability: URI Sanitization Failure Leads to Remote Code Execution

The root cause, classified as CWE-20 (Improper Input Validation), stems from insufficient sanitization of Uniform Resource Identifiers (URIs) processed by the Optix MQTT broker. By crafting a specially formatted URI, an attacker can instruct the broker to fetch and load a remote Mosquitto plugin — a dynamic library or module — from an attacker-controlled location. Once loaded, the malicious plugin runs with the privileges of the broker process, enabling arbitrary code execution.

Mosquitto supports plugin modules to extend broker functionality. Under normal conditions, plugins are supposed to be loaded from trusted, local directories. The Optix implementation, however, lacked strict validation, allowing a remote URI to point to an external plugin artifact. CISA’s advisory states that the vulnerability is exploitable remotely with high attack complexity. The CVSS v4 vector string (AV:N/AC:H/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) indicates that a successful exploit requires a low-privileged attacker and user interaction, but the technical description makes clear that an exposed MQTT endpoint is sufficient for an attack path.

Affected Versions and the Fix

  • Affected: FactoryTalk Optix versions 1.5.0 through 1.5.7.
  • Recommended action: Upgrade to FactoryTalk Optix 1.6.0 or later.

Rockwell Automation reported the vulnerability to CISA and has published a security advisory in its Trust Center. The corrected version, 1.6.0, removes the unsafe URI handling and presumably enforces a signed-plugin policy. CISA’s advisory, ICSA-25-252-04, was republished to ensure critical manufacturing and other sectors are aware.

Why ICS/OT Operators Must Treat This as Urgent

RCE vulnerabilities in HMI/SCADA products are among the most severe risks for industrial environments. A successful exploit could lead to:
- Deployment of ransomware that halts production lines.
- Manipulation of operator displays, causing operators to miss critical alarms or see false data.
- Alteration of setpoints that could physically damage equipment or endanger personnel.
- Lateral movement into safety-instrumented systems or other control network assets.

FactoryTalk Optix is deployed widely in critical manufacturing across many countries. Its MQTT broker, by design, is a networked service that often faces integration points with cloud analytics, historian databases, and contractor laptops. Organizations that have not strictly isolated broker traffic behind firewalls and VPNs may be vulnerable to remote exploitation.

The availability of a vendor patch reduces remediation complexity, but OT patching cycles often lag due to maintenance windows, compatibility testing, and safety validation. RCE risk, however, must be prioritized above routine operational constraints.

Practical Mitigation Roadmap

Operators should adopt a phased approach that balances security urgency with operational realities.

Immediate (Days 0–3): Tactical Containment

  • Patch priority: Begin testing FactoryTalk Optix 1.6.0 in a non-production environment.
  • Minimize exposure: Block all external access to Optix MQTT ports (typically 1883/8883) at perimeter firewalls and intra-site boundaries.
  • Segment network: Move the broker interface to a dedicated OT VLAN accessible only from trusted systems such as internal historians or analytics gateways. Enforce strict Access Control Lists (ACLs).
  • Temporary restrictions: If immediate patching is impossible, restrict broker access via firewall rules to only known, authorized IP addresses.

Near-Term (Days 3–14): Hardening and Detection

  • Disable remote plugin loading: Configure Optix/Mosquitto to reject remote URIs for plugin load. Restrict allowable plugin directories to signed, vendor-provided paths.
  • Application allow-listing: Prevent unauthorized binaries or libraries from loading into the broker process using AppLocker, WDAC, or similar whitelisting controls.
  • Enhanced logging: Enable verbose logging for the MQTT broker, capturing plugin load attempts. Forward logs to a central SIEM and create alerts for unexpected URI requests or dynamic library loads.
  • Network detection: Deploy IDS/IPS rules to detect anomalous MQTT traffic patterns, especially CONNECT messages containing plugin-related URIs. CISA’s technical guidance for ICS environments provides base indicator patterns that can be adapted.

Medium-Term (Days 14–90): Staged Rollout and Verification

  • Validate upgrade: Test Optix 1.6.0 thoroughly with existing HMI projects, cloud connections, and MQTT topic mappings. Ensure backward compatibility.
  • Staged deployment: Schedule patches during controlled maintenance windows. Prioritize systems that have exposed MQTT endpoints or are connected to business networks.
  • Post-deployment verification: After upgrading, attempt benign plugin load scenarios in a test environment to confirm the vector is closed. Review logs for any unexpected loads.
  • Update incident response playbooks: Include specific procedures for isolating compromised Optix hosts, revoking broker access, and forensic collection of broker process memory and logs.

Long-Term: Architectural Resilience

  • Reduce reliance on remote plugin loading: Design architectures so that only vendor‑approved, signed plugins are installed via strict deployment pipelines.
  • Vendor coordination: Require Rockwell Answer IDs (AIDs) and Vulnerability Exploitability eXchange (VEX) statements as part of procurement and patch management processes.
  • Use intermediaries: For any broker that must accept external integrations, deploy a gateway that sanitizes URIs and performs strict schema validation before forwarding traffic to the broker.

Detection and Threat Hunting

Even after patching, continuous monitoring is essential. Look for:
- Unusual outbound HTTP/S or TLS requests from the broker host, especially to unknown external IPs.
- Unexpected dynamic library loads by the broker process (visible via EDR telemetry).
- Abnormal MQTT traffic featuring plugin-loading URIs in CONNECT or PUBLISH packets.
- Spikes in child process creation from the broker process.

Correlate broker logs with firewall events and endpoint telemetry in a SIEM. Establish a baseline of normal MQTT topic activity and client connections, and alert on deviations.

Strengths and Gaps in Vendor and CISA Guidance

Strengths:
- Rockwell provided a clear upgrade path (to 1.6.0) and prompt notification.
- CISA’s repackaging elevates visibility for critical infrastructure defenders and includes actionable steps like network isolation and VPN usage.

Gaps and limitations:
- Some organizations rely solely on automated CVE feeds, which may lag behind vendor advisories. The CVE-2025-9161 record in the NVD may not have been fully populated at the time of the advisory release. Treat the CISA advisory and Rockwell’s Trust Center as primary sources.
- OT environments often cannot implement EDR/SIEM on HMI hosts due to performance or vendor constraints, reducing detection capabilities. Compensating network controls become even more critical.
- Disabling remote plugin loading entirely may break legitimate integrations if operators rely on that feature. Testing and careful configuration review are needed.

Conclusion

The URI sanitization flaw in FactoryTalk Optix’s MQTT broker is a high‑impact, remotely exploitable RCE vulnerability that combines a common middleware service with insufficient input validation. It is the kind of vulnerability that crosses software supply chain, networking exposure, and runtime trust boundaries — a trifecta that keeps industrial defenders awake at night.

Rockwell’s corrected release (Optix 1.6.0) is available now. Organizations running affected versions must act quickly: isolate exposed brokers immediately, test the upgrade, and deploy it in a staged but expedient manner. Hardening the broker runtime with allow‑listing and strict plugin policies reduces the attack surface for future flaws. In the modern ICS landscape, where HMI stacks mix Windows services, Node.js components, and open‑source brokers, treating every networked endpoint as a potential breach point is no longer optional — it’s operational necessity.

For the most current information, consult the CISA advisory (ICSA-25-252-04) and Rockwell Automation’s security advisory page.