CVE-2021-26829: OpenPLC ScadaBR Cross-site Scripting Vulnerability

CVE-2021-26829 is a cross-site scripting vulnerability in OpenPLC ScadaBR that can be triggered through the system_settings.shtm component. Cross-site scripting flaws of this class allow an attacker to inject malicious scripts that execute in the browser of a user who interacts with the affected interface. For industrial control and SCADA environments that rely on OpenPLC ScadaBR, successful abuse can lead to session hijacking, unauthorized configuration changes, or further compromise of operator workstations, which is why defenders should treat it as a priority for inventory and remediation.

CISA notes that the required action is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for any cloud-hosted instances, or discontinue use of the product if mitigations are unavailable. Ransomware use associated with this CVE is not documented.

How it works

The vulnerability is classified as CWE-79, improper neutralization of input during web page generation (cross-site scripting). In products of this class, user-controlled data reaches a web page without adequate encoding or validation. An attacker who can supply input that is later rendered by system_settings.shtm can cause a victim’s browser to execute attacker-controlled script in the security context of the OpenPLC ScadaBR application.

Typical abuse patterns for this weakness involve crafting a request or link that places the payload into a parameter or form field processed by the vulnerable page. When an authenticated operator or administrator loads the resulting page, the script runs with the privileges of that user’s session. Exact request formats, parameters, and authentication requirements must be confirmed against the vendor advisory; public detail beyond the CISA summary is limited.

Am I affected? How to find it in your systems

OpenPLC ScadaBR is commonly deployed as a web-based SCADA/HMI interface for monitoring and controlling industrial processes, often on dedicated servers, engineering workstations, or virtual machines inside operational technology networks. Inventory efforts should focus on any host running OpenPLC ScadaBR, especially those exposing a web management interface.

• Search asset inventories, CMDB records, and network scans for hosts advertising OpenPLC ScadaBR or related web services.
• Examine installed software lists and configuration files for references to ScadaBR and the system_settings.shtm endpoint.
• Confirm the exact software version and patch level against the vendor advisory; the facts supplied here do not list specific version ranges.
• Review web-server access logs for requests to system_settings.shtm that contain unexpected script tags, encoded payloads, or anomalous query strings—these may indicate probing or exploitation attempts.
• Where available, inspect browser console logs or security telemetry from operator workstations for evidence of unexpected script execution originating from the ScadaBR origin.

Because configuration and exposure details vary, treat any unpatched instance as potentially vulnerable until the vendor advisory is reviewed.

How to remediate

The primary remediation is to apply the vendor-supplied update or mitigation instructions for OpenPLC ScadaBR. Confirm the precise package, version, or configuration change against the official vendor advisory before deployment. After patching, verify that the system_settings.shtm page no longer accepts or reflects untrusted input without proper encoding.

• Follow any additional guidance provided by the vendor for secure configuration of the web interface.
• Where the product is used in cloud or managed environments, apply the applicable requirements of BOD 22-01.
• If mitigations cannot be applied, discontinue use of the product as directed by CISA.
• After remediation, re-inventory the environment and re-test the previously vulnerable endpoint to confirm the fix.

Hardening steps common to this class of web application include enforcing strict output encoding, implementing a content-security policy, and restricting administrative access to trusted networks only.

If you can't patch immediately

Until the vendor update can be applied, reduce exposure with compensating controls appropriate to SCADA and web-management interfaces.

• Segment the OpenPLC ScadaBR host so that only authorized engineering and operations networks can reach the web port; block direct internet or corporate-desktop access.
• Place a web application firewall or reverse proxy in front of the interface and enable rules that detect and block common cross-site scripting patterns targeting system_settings.shtm; treat this as temporary virtual patching and validate rules carefully to avoid disrupting legitimate operations.
• Disable or restrict access to the system_settings.shtm functionality if operational requirements allow.
• Enforce multi-factor authentication and least-privilege accounts for any remaining administrative sessions.
• Increase monitoring of authentication events, configuration changes, and web-access logs for the affected host; alert on anomalous requests to system_settings.shtm.

These measures lower risk but do not eliminate the underlying flaw; schedule permanent remediation as soon as possible.

If your data may have been exposed

Actively exploited vulnerabilities can lead to unauthorized access and data exposure even when ransomware use is not documented for a specific CVE. Review logs for signs of successful script injection or subsequent lateral movement, rotate any credentials that may have been handled through the ScadaBR interface, and assess whether process or configuration data could have been viewed or altered. You can run a free exposure scan of your email addresses against known breach data sets to determine whether related accounts appear in public breach corpora, then take appropriate credential-reset and monitoring steps.