What Is CVE-2021-26829 (OpenPLC ScadaBR Cross-site Scripting)?

By NHI Mgmt Group Updated October 17, 2026 Domain: Threats, Abuse & Incident Response

CVE-2021-26829 is a cross-site scripting vulnerability in OpenPLC ScadaBR. CISA added it to the Known Exploited Vulnerabilities catalogue on 28 November 2025, which means attackers have used it in real attacks. OpenPLC ScadaBR contains a cross-site scripting vulnerability via system_settings.shtm.

What this vulnerability means in OpenPLC ScadaBR

Cross-site scripting in a web-based control interface means an attacker can inject script into a page that a legitimate operator later loads. In an HMI or SCADA context, that matters because the interface often sits close to operational control, alerting, and privileged administration.

For a vulnerability like CVE-2021-26829, the core issue is not just browser-side script execution, but trust abuse inside an operational web console. If a user opens the affected page, malicious script can run in their session context and interact with the application as if it were that user.

Why XSS is dangerous in industrial web applications

XSS can expose live session state, modify what an operator sees, or trigger actions through the victim’s authenticated browser session. In systems used for monitoring or control, that can distort situational awareness and create unsafe decision-making conditions.

The danger increases when the vulnerable page sits in an administrative workflow or when operators reuse privileged sessions. Even if the exploit starts as a browser issue, the practical effect can become access abuse, data tampering, or a stepping stone to deeper compromise.

For background on the vulnerability class itself, CVE Program entries define how identifiers are assigned and tracked, while the NIST National Vulnerability Database is the place to confirm canonical record details and related product metadata.

How organisations assess exposure and limit blast radius

The first step is to confirm where the affected OpenPLC ScadaBR instance exists, who can reach it, and whether it is exposed beyond tightly controlled operator networks. Internet-facing exposure, shared admin access, and weak segmentation all increase the practical impact of an XSS flaw.

Exposure review should include asset inventory, vendor advisories, and any compensating controls already in place around the web interface. For broader vulnerability triage and KEV-driven prioritisation, the Vulnerability Management Guide is useful for aligning discovery, prioritisation, and verification with exploit reality.

When an interface is reachable by multiple roles, organisations should assume the browser session itself becomes part of the attack surface. That makes session handling, privilege boundaries, and operator workflow design part of the exposure assessment, not just the patch plan.

Remediation, detection, and post-exploitation review

The preferred remediation is vendor guidance plus a patched release, but when patching cannot happen immediately, organisations should reduce exposure by restricting access, hardening session handling, and limiting where the console can be reached from. Temporary controls are only substitutes until the vulnerable page is corrected.

Detection should focus on unusual script behaviour, unexpected requests from authenticated operator browsers, and any signs that console content has been altered or chained into other actions. After remediation, review logs and user activity for signs that the vulnerability was exercised before the fix was applied.

If exploitation is suspected, treat any credentials, active sessions, or privileged browser contexts used through the affected interface as potentially exposed and review them for renewal or revocation where appropriate. For general web attack patterns and defensive context, Web Application Attacks Guide provides a useful map of XSS and related injection paths.

Risk and Threat Considerations

Cross-site scripting in an operational interface can be used to hijack trust inside an authenticated session, which makes the flaw more dangerous than a simple browser nuisance. In environments where operators rely on the same console for supervision and control, the attacker may be able to manipulate what a trusted user sees or does.

Failure mechanism: Malicious script executes in the victim’s browser under an authenticated session, allowing the attacker to steal session data, alter page content, or trigger trusted actions through the console.

Impact: The result can be operator deception, unauthorized interaction with the application, exposure of sensitive operational data, and a wider path into adjacent systems if the session has elevated reach.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V1 — Encoding and Sanitization	XSS is prevented by robust encoding and sanitization of untrusted input.
	V7 — Session Management	XSS can act through authenticated browser sessions and session state.
	V8 — Authorization	Script execution in a trusted session can abuse application actions and permissions.
Recommendation — Apply V1 controls to encode and sanitize all untrusted content before it reaches the browser. Apply V7 controls to reduce session theft and limit what a compromised browser session can do. Apply V8 controls so browser-side injection cannot perform actions outside intended authorization.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	XSS is an input-validation failure that lets attacker-controlled content reach rendering paths.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-patch review depends on logs and audit trails to detect exploitation and abuse.
Recommendation — Enforce SI-10 to validate and reject unsafe input before it is rendered or processed. Use AU-6 to review logs for evidence of script abuse, session misuse, and post-exploitation activity.
CIS Controls v8	CIS-16 — Application Software Security	Application flaws like XSS are addressed through secure development and testing practices.
Recommendation — Use CIS-16 to identify and remediate XSS during development and validation.

Practitioner Guidance

What to watch for: Treat XSS in industrial and administrative web tools as a session-integrity problem, not only an input-validation issue. The most important question is whether the affected page is reachable by privileged users or exposed in a way that lets malicious content influence real operational decisions.

Governance implication: Ownership should sit with both the application team and the operational system owner, because remediation, access design, and post-incident review all affect safety and trust. That shared accountability is especially important when the console supports control-room workflows.

Practitioner takeaway: If the page can be loaded by a trusted operator, assume the browser session is part of the security boundary and verify it accordingly.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org

CVE-2021-26829 (OpenPLC ScadaBR Cross-site Scripting)