CVE-2021-26829

What it actually does

CVE-2021-26829 is a stored cross-site scripting vulnerability in OpenPLC ScadaBR affecting Linux versions through 0.9.1 and Windows versions through 1.12.4. A low-privileged authenticated user can store attacker-controlled script content through the system_settings.shtm functionality. When another user, such as an administrator or operator, later views the affected settings page, the browser executes the script in the context of the ScadaBR web application. This can allow theft of session data, unauthorized actions using the victim's privileges, modification of displayed SCADA information, or pivoting to other browser-accessible systems. The CVSS score is 5.4, but the vulnerability is listed in CISA KEV and has active in-the-wild exploitation, which materially raises operational urgency.

Why it matters to the business

Successful exploitation can let an attacker manipulate a SCADA operator's browser session, potentially changing application settings, misleading operators, or performing actions as a more privileged user. In industrial or operational technology environments, even a browser-based compromise can disrupt monitoring workflows, reduce trust in displayed process data, and create a foothold for broader intrusion activity. Because this vulnerability is in the CISA Known Exploited Vulnerabilities catalog with a remediation due date of 2025-12-19 and an EPSS score of 0.4805, organizations running affected OpenPLC ScadaBR versions should treat exposure as a priority even though the base CVSS rating is moderate.

How an attack unfolds

An attacker first obtains access to a ScadaBR account with permission to reach the system settings functionality. The attacker submits malicious JavaScript through system_settings.shtm in a field that is stored by the application without adequate sanitization. The payload remains in the application until removed. When an administrator or operator opens the affected settings page, the stored script executes in that user's browser under the trusted ScadaBR origin. The script can then read page content available to the user, issue authenticated requests to the application, alter what the user sees, redirect the user to attacker-controlled infrastructure, or attempt to capture session-related material where browser controls allow it. Public exploitation is reported and the vulnerability is KEV-listed; threat reporting associated with this item should be reviewed carefully for environment relevance, including references to OpenPLC ScadaBR exploitation campaigns.

How to fix it

Upgrade OpenPLC ScadaBR to a version that contains the vendor fix once available for the deployed platform; the supplied advisory data does not provide exact fixed version numbers. Linux deployments through 0.9.1 and Windows deployments through 1.12.4 should be considered affected. If an immediate upgrade is not possible, restrict access to ScadaBR to trusted management networks or VPN-only access, remove public internet exposure, limit the number of users with access to system settings, enforce least privilege, and require re-authentication for administrative changes where supported. Review and remove suspicious stored content from system settings fields. Apply compensating controls at a reverse proxy or WAF to block obvious script payloads, event-handler attributes, and javascript: URLs, but do not rely on filtering as a permanent fix. For operational technology deployments, coordinate patching with change-control and safety procedures while prioritizing systems reachable from enterprise networks or the internet.

How to confirm the fix worked

Confirm the deployed OpenPLC ScadaBR version on each Linux and Windows host and verify it is newer than the affected ranges or includes the vendor's security correction. Browse system_settings.shtm using a test account and confirm user-supplied settings are output-encoded and do not execute HTML or JavaScript. Review stored system settings values directly through the application or configuration storage and verify no script tags, event-handler attributes, iframe tags, encoded JavaScript, or suspicious external URLs are present. Validate that ScadaBR is not internet-exposed unless explicitly required and protected. Confirm administrative functions are reachable only from approved networks. After remediation, clear any malicious stored values, invalidate active sessions, rotate credentials for users who viewed the affected page, and retest with a harmless XSS probe such as a non-executing marker string rather than a live payload.

Typical attack path

1. Identify an exposed or internally reachable OpenPLC ScadaBR instance running an affected version.
2. Authenticate with a low-privileged account or obtain credentials through separate means.
3. Browse to system_settings.shtm or the equivalent system settings workflow.
4. Submit a stored XSS payload in a vulnerable settings field.
5. Wait for a higher-privileged user to view the affected settings page.
6. Execute JavaScript in the victim user's browser session.
7. Use the victim's application privileges to read data, change settings, create persistence inside the application, or stage additional attacks.

How to detect it

To determine whether exploitation already occurred, review ScadaBR web access logs, reverse proxy logs, application logs, and any database or configuration records that store system settings. Focus on requests to system_settings.shtm that include script tags, HTML event handlers, encoded JavaScript, iframe/object/embed tags, external URLs, or suspicious redirects. Correlate suspicious settings changes with subsequent administrator or operator visits to the same page, especially if followed by unexpected configuration changes, new users, privilege changes, credential changes, or outbound web requests from user workstations to unfamiliar domains. Examine browser history, cached pages, proxy telemetry, and EDR data for users who accessed the affected page. Look for JavaScript execution artifacts, unexpected network callbacks, downloads, or redirects occurring immediately after visits to the ScadaBR settings page. Because this issue is known to be exploited in the wild, review historical logs back to the earliest available retention period, not only recent activity. Threat-intelligence references tied to OpenPLC ScadaBR exploitation should be correlated with observed source IPs, payload patterns, and infrastructure, but campaign labels should not be treated as proof of attribution without supporting evidence.

• system_settings.shtm
• GET /system_settings.shtm
• POST /system_settings.shtm
• <script
• </script>
• %3Cscript
• %3C%2Fscript%3E
• javascript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• onerror=
• onload=
• onclick=
• onmouseover=
• <iframe
• %3Ciframe
• document.cookie
• localStorage
• sessionStorage
• eval(
• new Image().src
• fetch(
• XMLHttpRequest
• window.location
• document.location

What your security team should do

• Inventory all OpenPLC ScadaBR deployments and prioritize Linux versions through 0.9.1 and Windows versions through 1.12.4.
• Treat this as urgent because it is CISA KEV-listed, actively exploited in the wild, and has a 2025-12-19 KEV remediation deadline.
• Remove direct internet exposure and restrict ScadaBR access to trusted administrative networks while patching is planned.
• Upgrade to a corrected OpenPLC ScadaBR release or migrate away from unsupported affected versions if no fixed build is available.
• Search application data and logs for stored XSS payloads in system settings values and remove any suspicious content.
• Review accounts with access to system_settings.shtm and reduce privileges to the minimum required.
• Invalidate sessions and rotate credentials for privileged users who may have viewed the affected settings page during the suspected exposure window.
• Add SIEM detections for script-like content submitted to system_settings.shtm and for unusual administrative actions immediately after settings page access.
• Coordinate remediation with OT operations teams to avoid unsafe disruption while still meeting KEV-driven deadlines.