Rockwell DataMosaix Private Cloud patch fixes MFA bypass and XSS CVEs

Rockwell Automation has published fixes for two high‑impact vulnerabilities in FactoryTalk DataMosaix Private Cloud — an MFA bypass that can produce a valid login token without a password (CVE‑2025‑11084) and a persistent cross‑site scripting flaw that can enable account takeover or credential theft (CVE‑2025‑11085) — and operators running the affected releases must treat this as an immediate patching priority.

Background / Overview​

FactoryTalk DataMosaix Private Cloud is Rockwell Automation’s customer‑managed Industrial DataOps platform designed to bridge OT and IT data, expose visualizations, and provide open APIs and connectors to analytics systems. The product is widely deployed in critical manufacturing environments, where availability and integrity are as important as confidentiality. Two newly cataloged CVEs affect DataMosaix deployments:

• CVE‑2025‑11084 — an MFA bypass / weak authentication condition that can be abused during account setup when multi‑factor authentication (MFA) is enabled but not completed within seven days. Rockwell assigns this to CWE‑1390 (Weak Authentication) and reports CVSS v3.1 = 6.8 and CVSS v4 = 7.6.
• CVE‑2025‑11085 — a persistent XSS vulnerability in the web interface, categorized as CWE‑116 (Improper Encoding or Escaping of Output) and scored by Rockwell at CVSS v3.1 = 8.0 and CVSS v4 = 8.6. Successful exploitation can execute arbitrary JavaScript in administrator or operator browsers.

Rockwell has published corrected builds: upgrade to DataMosaix 8.02 to remediate CVE‑2025‑11084 and to DataMosaix 8.01 to remediate CVE‑2025‑11085. Operators who cannot upgrade immediately are urged to implement compensating controls while scheduling patch testing and rollout.

---

Why this matters for industrial and Windows teams​

Industrial control systems (ICS) and OT platforms increasingly run hybrid stacks — web UIs, Windows‑based engineering workstations, cloud‑style APIs and third‑party libraries — expanding the attack surface the moment web‑facing components or management endpoints are reachable from a less‑trusted network. A persistent XSS in an admin console or an MFA bypass that yields a valid session token can be leveraged by attackers to pivot, steal credentials, or take over accounts used for management tasks. Those chains are particularly damaging in critical manufacturing, where unauthorized changes can halt production or create safety hazards. CISA and national vulnerability repositories mirror the vendor findings and emphasize the operational risk posed by network‑accessible attack vectors and low‑complexity exploits for some DataMosaix issues. These sources have not observed public exploitation at the time the advisories were published, but the combination of web UI weaknesses and authentication flaws keeps the window for opportunistic attacks open until patches are applied.

---

Technical deep dive​

CVE‑2025‑11084 — MFA bypass (Weak Authentication)​

• What it is: Under specific account provisioning conditions — when an account is configured for MFA but the MFA registration step remains incomplete for up to seven days — an attacker can derive or obtain a valid login‑token cookie without knowing the account password. That token can be used for authenticated access as the victim user. Rockwell classifies the underlying weakness as weak authentication (CWE‑1390).
• Attack vector and complexity: The vendor’s scoring and vector strings identify the flaw as involving an adjacent network or administrative relationship in some evaluations (CVSS v4 vector AV:A/AC:H …), but the practical effect is that an attacker who can reach the affected provisioning endpoints or trick an operator during a provisioning/registration window may cause token issuance without credentials. The attack complexity varies depending on network placement and the operator’s account provisioning workflow.
• Primary impacts:
• Account takeover without password theft.
• Bypass of MFA guarantees, undermining a primary protection for remote and privileged access.
• Ability to perform actions as the targeted user (view/modify data, call APIs, etc. depending on user privileges.
• What the vendor fixed: Rockwell’s 8.02 release updates the setup/provisioning flow to ensure incomplete MFA registrations cannot be used to derive or issue valid tokens, and applies stricter session/token issuance checks. Operators should confirm the patched behavior in a non‑production test bed before rolling to production.

CVE‑2025‑11085 — Persistent cross‑site scripting (XSS)​

• What it is: An input/encoding failure in the DataMosaix web UI allows attacker‑controlled data to be stored and later rendered without sufficient encoding/escaping, delivering active script to the browser of an admin or operator who views the affected UI element. Rockwell classifies this as CWE‑116.
• Attack vector and complexity: This is a network‑accessible web vulnerability and is typical of stored XSS — the attacker must get their payload saved in the application (via a field, upload, or configuration entry) and then wait for an authenticated victim to load the page. Exploitation often requires some level of privilege to write data; however, once rendered it can escalate to credential theft, session capture, or forced actions in the context of an admin session. CVSS scoring reflects the high potential impact.
• Primary impacts:
• Session token theft or session fixation via script‑based extraction of cookies/localStorage tokens.
• Credential harvesting via fake login overlay or form grabbing.
• Administrative action automation (CSRF‑style commands executed through the victim’s browser).
• Phishing/redirects to attacker‑controlled pages for secondary social engineering.
• What the vendor fixed: Rockwell’s 8.01 release hardens output encoding and input sanitization for the affected UI fields and introduces server‑side validation to reject dangerous payloads at the write path. As with any XSS fix, operators should test use cases that rely on complex HTML or embedded content to avoid functional regressions.

---

Risk evaluation — realistic attack scenarios​

• Scenario 1 — MFA bypass to persistent access: An attacker with network access to a provisioning endpoint induces or intercepts the incomplete MFA state for a target account, obtains a valid login token, and then uses that token to access dashboards and APIs with the victim’s privileges. This removes the need to phish passwords and can be combined with lateral movement to reach engineering tools.
• Scenario 2 — Stored XSS leads to credential theft: An authenticated but low‑privileged operator uploads or creates data containing a malicious script (or an attacker with write permission injects it). When a privileged user views the UI, the script exfiltrates cookies/session tokens or performs actions as the privileged user, enabling configuration changes or data export.
• Compound risk: When web UI scripting vulnerabilities exist alongside authentication weaknesses (or misconfigurations), the resulting attack chain can be powerful: XSS can be used to automate misuse of an account that the MFA bypass would otherwise be needed to take over. That multiplicative risk is why rapid patching and network controls are essential.
• Exploitation status: At the time the advisories were published, Rockwell and national registries report no known active exploitation of these specific CVEs. That does not mean the risk is hypothetical — just that defenders have a window to respond before widespread exploit code typically appears. Treat the absence of observed exploitation as a limited benefit rather than proof of safety.

---

Vendor and agency response — strengths and limitations​

• Strengths:
• Rockwell promptly assigned CVE identifiers, published a security advisory (SD1758), and released corrected builds with specific version numbers for remediation. That transparency and the delivery of fixed releases are positive for operational teams that need clear upgrade paths.
• National vulnerability databases (NVD) and third‑party trackers have ingested and mirrored the vendor findings, which helps defenders correlate risk across tooling and management consoles.
• Limitations and open questions:
• The MFA bypass depends on a timing/window condition in account setup. Organizations are heterogeneous: some may have provisioning workflows that keep incomplete MFA states open for longer or replicate them across environments, increasing exposure. Operators must verify their specific configurations rather than assume vendor defaults.
• Patching operational ICS systems is non‑trivial. Many facilities defer updates for availability reasons; the vendor provided no universal temporary workaround that fully eliminates risk, so organizations must balance testing needs with urgent remediation.
• The advisory notes no public exploitation, but the lack of observed attacks is not a guarantee — private or targeted attacks could be unreported. Maintain a cautionary posture.

---

Prioritized mitigation checklist (what to do now)​

Apply the following steps in order of priority. These recommendations assume minimal downtime is acceptable for patching; if downtime is restricted, apply compensating controls in parallel.

• Inventory and exposure assessment
• Identify every DataMosaix Private Cloud instance, its exact version (7.11, 8.00, 8.01, etc., and network exposure (public internet, DMZ, enterprise network).
• Confirm which user provisioning workflows or SSO/MFA integrations exist; document any automation that might leave accounts in an incomplete MFA state for more than seven days.
• Patch planning and testing
• Schedule a staged upgrade: apply 8.01 for XSS remediation and 8.02 for the MFA bypass in a non‑production test environment, validate critical integrations (APIs, connectors, analytics exports), and then roll to production.
• Follow change control and rollback procedures; test backup and restore of configuration and persistent data before upgrade.
• Short‑term compensating controls (if you cannot patch immediately)
• Minimize network exposure: block or restrict access to management endpoints and admin consoles to trusted subnets only, ideally via jump hosts or bastion systems. Apply firewall rules to restrict inbound connectivity.
• Harden remote access: require VPN access with multi‑factor protection for administrative access points and monitor the gateways closely. Keep VPN appliances updated.
• Session and token hygiene: reduce token lifetimes where possible, invalidate pending/partially‑completed MFA states, and rotate session keys to remove any tokens that could have been issued prior to the fix. If the product exposes a way to invalidate all sessions, use it after patching to prevent reuse. (Note: verify the product’s session invalidation behavior in test.
• Web application hardening
• Deploy a Web Application Firewall (WAF) with rules tuned to detect XSS payload patterns and block suspicious content writes and reflected script payloads.
• Enforce Content Security Policy (CSP) headers, secure cookies (HttpOnly, Secure, SameSite), and appropriate X‑Frame‑Options and X‑Content‑Type‑Options headers at the web server or application gateway to reduce the blast radius of any client‑side script injection.
• Monitoring and detection
• Add logging and alerting for:
• Unexpected session creation or token issuance during provisioning windows.
• Unusual POST/PUT requests to configuration endpoints or fields that accept HTML/markup.
• Unusual administrative browser activity (sudden config changes, export of projects) and any privilege escalations.
• Integrate logs into SIEM/EDR and create detection rules for suspicious XSS payload patterns and session token anomalies.
• Post‑patch validation
• After installing 8.01/8.02, perform a targeted penetration test of the provisioning flow and UI fields previously identified as vulnerable to confirm the fix.
• Reissue/rotate keys and tokens as necessary and confirm that invalidation worked as expected.

---

Detection and response playbook (executable steps)​

• Triage checklist for a suspected compromise:
• Isolate the affected DataMosaix instance from external networks.
• Collect and preserve logs (web server, application, authentication, OS) and system images for forensic inspection.
• Invalidate all active sessions and rotate service accounts and API keys where feasible.
• Search logs for indicators: anomalous token creation timestamps, unusual provisioning events, and creation of projects or uploads in admin contexts.
• Indicators of Compromise (IoCs) to look for:
• Unexpected session token issuance timestamps tied to accounts with incomplete MFA enrollment.
• POST requests containing JavaScript fragments or encoded script payloads in fields that should not contain scripts.
• Admin‑level actions executed from unusual source IP addresses immediately after token issuance.
• Recovery steps:
• Restore affected services to patched images, re‑establish hardened access controls, and perform a full credential rotation for service and privileged accounts.
• Run a complete configuration comparison to detect unauthorized changes (network rules, connector endpoints, plugin installs).

---

Hardened long‑term posture for Industrial DataOps platforms​

• Apply the principle of least privilege to all service and user accounts interacting with DataMosaix and integrate with enterprise identity providers where possible for centralized policy control and session revocation.
• Maintain an accurate asset inventory and configuration baseline for every DataMosaix instance: version, installed connectors, upstream/downstream integrations, and network access controls.
• Regularly test provisioning flows and admin UIs for input validation, output encoding, and session management to catch introduction of regressions or new weaknesses.
• Adopt a planned, annual ICS/OT patching and validation cadence that includes vendor advisories monitoring, test deployment windows, and contingency rollback procedures.
• Consider isolating critical management services on physically or logically separate networks and using jump boxes for all admin connections.

---

Critical analysis — takeaways and residual risks​

• The vendor response is timely and specific: Rockwell assigned CVEs, published an advisory (SD1758) and released fixed builds with explicit version numbers. That clarity facilitates a straightforward remediation path, which is a best practice for enterprise and industrial vendors today.
• However, operational realities create residual risk:
• Many organizations delay ICS/OT patching because of uptime, compatibility, or validation constraints. When a patch has no simple hotfix or workaround, compensating network controls and session‑management mitigations become the only practical short‑term defense — and those controls are only as good as the organization’s segmentation and monitoring maturity.
• The MFA bypass vulnerability highlights the importance of provisioning process security. MFA is often treated as a binary on/off control, but the implementation details around incomplete enrollment and token issuance are operationally critical and often overlooked in vulnerability management.
• Transparency note: public sources report no known active exploitation at advisory publication, and the CVE records are derived from Rockwell’s advisory. Treat the "no exploitation observed" status as temporal — attackers frequently develop weaponized exploits soon after vendor disclosures become public. Rapid validation and patching remain the prudent response.
• Unverifiable or environment‑specific claims: The exact ease of exploiting the MFA bypass in a given network depends heavily on local provisioning flows, SSO integrations and how long incomplete registrations are permitted. Operators should assume their environment may be vulnerable until they confirm otherwise through testing rather than relying on generalized descriptions in advisories. This is an important caveat when applying vendor guidance to complex industrial deployments.

---

Final recommendations — immediate action list​

• Patch now: Prioritize deployment of DataMosaix 8.01 (XSS) and 8.02 (MFA bypass) after validating in a test environment. Schedule production rollout with rollback plans.
• Segment and restrict: Immediately restrict access to the DataMosaix management plane to trusted networks and jump hosts; block direct internet access.
• Invalidate and rotate: After patching, invalidate outstanding sessions and rotate service credentials and API keys that may have been exposed.
• Harden web defenses: Deploy WAF rules and CSP headers; ensure cookies are HttpOnly/Secure/SameSite; monitor for XSS indicators.
• Monitor actively: Add specific SIEM alerts to detect token issuance anomalies, provisioning window activity, and suspicious admin UI actions.
• Test provisioning flows: Confirm incomplete MFA states cannot be abused in your custom provisioning or SSO workflows; close any workflow‑specific gaps found.

---

Industrial control systems and DataOps platforms are prime targets because they touch both operational processes and enterprise data. The newly disclosed CVE‑2025‑11084 (MFA bypass) and CVE‑2025‑11085 (persistent XSS) present credible, high‑impact risks that are addressable through the vendor fixes Rockwell has released and through defensive network and application controls. Treat these advisories as actionable: inventory your DataMosaix instances, test the vendor updates in a controlled environment, and deploy patched versions rapidly while applying compensating controls until upgrades are complete. Doing so reduces the chance that a single web UI bug or a provisioning edge case becomes an operational outage or a costly security incident.

---

Source: CISA Rockwell Automation FactoryTalk DataMosaix Private Cloud | CISA