CISA Adds OpenPLC ScadaBR CVE-2021-26828 to KEV: Urgent OT Defense

CISA’s addition of an OpenPLC ScadaBR vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog puts industrial control system defenders back on high alert: the flaw—reported in 2021 as an unrestricted upload of file with dangerous type that permits uploading and execution of arbitrary JSP files via the view_edit.shtm endpoint—has confirmed real‑world exploitation and now appears on the agency’s living list of high‑risk CVEs that federal agencies must prioritize.

Background / Overview​

OpenPLC ScadaBR is an open‑source Java‑based supervisory control and data acquisition (SCADA) system used in small to medium industrial deployments and academic environments. In June 2021 the project and public vulnerability databases recorded CVE‑2021‑26828 as a vulnerability that allows remote authenticated users to upload and execute arbitrary JSP files using the product’s view_edit.shtm functionality—effectively an authenticated web‑shell or remote code execution (RCE) vector in vulnerable installations. The Cybersecurity and Infrastructure Security Agency (CISA) maintains the Known Exploited Vulnerabilities Catalog under Binding Operational Directive (BOD) 22‑01 to force prioritization of vulnerabilities that are already being weaponized. When CISA adds a CVE to the KEV list, Federal Civilian Executive Branch (FCEB) agencies are required to remediate according to strict timelines spelled out by the directive; CISA also urges private organizations and critical infrastructure operators to follow the same urgency. The KEV process intentionally targets vulnerabilities where active exploitation has been observed, and CISA’s public guidance defines remediation and temporary mitigation expectations for affected systems.

---

What CISA announced (and what to watch for)​

CISA’s recent alert — posted to its “Adds One Known Exploited Vulnerability to Catalog” series — identifies an OpenPLC ScadaBR vulnerability for inclusion in the KEV, citing evidence of active exploitation. Multiple security news outlets and industry trackers reported the agency’s action and the observed exploitation patterns in recent weeks, bringing renewed focus to legacy SCADA software and default‑facing HMI endpoints. Note: there are multiple related ScadaBR CVEs from 2021 (including a stored XSS tracked as CVE‑2021‑26829 and the arbitrary file upload CVE‑2021‑26828). Public reporting around this KEV addition has referred to both identifiers in different contexts; analysts and admins should confirm the exact KEV entry on CISA’s catalog and match it to their inventory to avoid gaps in response. Key operational takeaways from the announcement:

• CISA added the ScadaBR vulnerability to the KEV Catalog after confirming active exploitation against targets in the wild.
• The technical root cause is unrestricted upload of dangerous file types (CWE‑434) permitting arbitrary JSP files to be uploaded and executed via view_edit.shtm, enabling attackers who gain an authenticated session to deploy web shells and take code execution actions.
• Under BOD 22‑01, agencies must remediate vulnerabilities on the KEV list within required timeframes; defenders should map affected components and apply vendor patches, mitigations, or remove the component from networks where updates are unavailable.

---

Technical profile: CVE‑2021‑26828 (what the vulnerability does)​

A compact, actionable description​

• Vulnerability type: Unrestricted upload of file with dangerous type (CWE‑434).
• Affected component: ScadaBR web interface, specifically the view_edit.shtm upload handler.
• Impact: Authenticated remote users may upload JSP files which are subsequently executed by the server, resulting in arbitrary code execution within the application context and potential system compromise.

Affected versions​

Public vulnerability records list affected ScadaBR versions as:

• Linux builds up to and including 0.9.1
• Windows builds up to and including 1.12.4
  Administrators should validate their exact product and build numbers against these ranges; forks or downstream distributions can change file paths, behaviour, or mitigations.

Attack prerequisites and ease of exploitation​

• Requires authenticated access to the web interface—an important but not insurmountable barrier in real environments where default credentials, weak passwords, or exposed management interfaces are common.
• Attack complexity is low once authentication is achieved: uploading a crafted JSP payload through the vulnerable endpoint is the core exploit step. Public proof‑of‑concepts and exploit tooling have circulated since 2021, increasing the chance of opportunistic attackers weaponizing the issue.

---

Evidence of exploitation and the current threat landscape​

CVE‑2021‑26828 (and the family of related ScadaBR issues) have public proof‑of‑concept code, packetstorm writeups, and demonstration videos that have been available since 2021. Security trackers and vulnerability databases mark the flaw as high severity (CVSS v3.1 base score 8.8 in several records), and some exploitation risk scoring services have assigned elevated EPSS probabilities and “exploit exists” tags—indicators that the vulnerability is both attractive and practical for attackers. Recent industrial‑sector reporting ties active exploitation to opportunistic malicious actors probing exposed HMI endpoints and using default credentials to escalate into full HMI compromise. Important nuance: public reporting and vendor/fork responses note two related 2021 ScadaBR CVEs—one an arbitrary file upload (CVE‑2021‑26828) and a separate stored XSS (CVE‑2021‑26829). Some press items describe the KEV addition referencing the ScadaBR XSS, others the file upload. This divergence emphasizes the operational need to verify which CVE is listed in an agency’s KEV notification and to map both issues into asset inventories.

---

Why this matters to federal agencies and critical infrastructure​

BOD 22‑01 makes the KEV Catalog a compliance and operational priority for FCEB agencies. The directive’s remediation timelines and mandatory reporting obligations force agencies to triage KEV entries rapidly. The specific reasons ScadaBR and similar OT/ICS vulnerabilities are consequential:

• SCADA/HMI components directly influence industrial processes; compromise can result in disrupted operations, manipulated setpoints, falsified telemetry, or safety‑critical actions.
• Many OT deployments use legacy software, incomplete patching, or default management configurations, raising the likelihood that an attacker who obtains even low‑privilege access can escalate impact.
• Public PoCs and exploit automation lower the attacker skill ceiling; once an exploit is known and works at scale, scanning and exploitation activity often accelerates.

BOD 22‑01 timelines: CISA’s directive requires agencies to remediate KEV entries per the catalog’s timelines—typically within two weeks for most recent CVEs and within six months for older CVEs assigned prior to 2021—unless CISA specifies a different due date. This means that when CISA adds a 2021 CVE that is actively exploited, agencies should expect to move fast. Administrators must check the KEV entry for the official due date and required actions.

---

Practical remediation and containment steps (what to do now)​

The following checklist is written for defenders responsible for Windows and Linux‑hosted ScadaBR instances and for network teams protecting OT/ICS segments.

1. Inventory and identify
   1. Map all instances of ScadaBR / OpenPLC in your environment, capturing version/build, OS, and any exposed management interfaces.
   2. Prioritize internet‑facing and DMZ‑exposed instances for immediate review.
2. Apply vendor or community patches (if available)
   1. Check upstream OpenPLC/ScadaBR repositories and maintained forks (and downstream vendor advisories) for fixes or updated forks that remove the vulnerable upload handler. Apply updates per vendor/community guidance.
3. If patching is not immediately possible: temporary mitigations
   • Disable or restrict access to the view_edit.shtm endpoint (disable file upload functionality) until a patch is applied.
   • Implement network controls: restrict HMI web UI access to trusted management subnets and jump hosts, apply ACLs, and block internet access unless explicitly required.
   • Enforce multi‑factor authentication and rotate default credentials for all admin and HMI accounts.
   • Remove or quarantine end‑of‑life ScadaBR installations; if an update is impossible, plan replacement or network isolation.
4. Hunt and detect compromise indicators
   • Look for suspicious POST requests to view_edit.shtm and any POST bodies containing JSP code signatures (e.g., <%@ page %>, <% out.print %>).
   • Scan for unexpected *.jsp files or webshell artifacts in upload directories, and monitor for new or anomalous user accounts created around the time of suspicious activity.
   • Audit process lists and web server logs for command execution, unexpected process spawns, or outbound command-and-control (C2) connections.
   • Use IDS/IPS rules to detect typical JSP web‑shell behaviours and HTTP patterns tied to public PoCs.
5. Incident response and recovery
   • If exploitation is confirmed, isolate the affected system from OT networks, preserve full evidence (system images, logs, memory snapshots), and follow incident response playbooks tailored for OT environments.
   • Replace or rebuild compromised HMI hosts from known‑good images, update credentials, and validate integrity of PLC logic and setpoints before reconnecting to production.
   • Engage with service vendors, OT integrators, or CISA if federal systems are impacted or if the incident crosses critical infrastructure boundaries.

---

Detection examples and a short hunting quicklist​

• Regex to find JSP upload attempts in logs (operational example): search HTTP POST bodies for JSP markers like <%@ page|<% out.print|<jsp:useBean.
• Search web roots for recently modified *.jsp files and compare against baseline.
• Monitor for user accounts created mid‑session or accounts used from novel IP addresses to access admin pages.
• IDS rule idea: alert on HTTP POST to /view_edit.shtm with content length > 1KB and presence of JSP token strings.

These are generic hunting starting points; every environment should tune thresholds and whitelists to minimize false positives and avoid disrupting OT operations.

---

Risks, caveats, and a note on attribution​

• Risk amplification: an attacker who successfully uploads and executes a JSP file can pivot from the HMI to connected controllers, tamper with operator displays, or create persistent backdoors that survive restarts. The industrial context increases the safety and public‑impact stakes of such a compromise.
• Evidence uncertainty and CVE identifiers: public reporting around CISA’s KEV addition has mentioned both CVE‑2021‑26828 (JSP upload) and CVE‑2021‑26829 (stored XSS) in different pieces. Analysts should not assume they are interchangeable; verify the exact KEV entry (CVE number and CISA due date) in the official catalog and align remediation actions accordingly. If any CISA alert text conflicts with other reporting, treat the official KEV catalog entry and the BOD‑posted due dates as authoritative.
• Public PoCs and EPSS: the availability of proof‑of‑concept code and exploit writeups since 2021, combined with elevated EPSS/exploit tags on vulnerability trackers, means opportunistic attackers can and will scan for unpatched instances; expect scanning and opportunistic exploitation attempts to continue.
• Attribution: some industrial incident investigations have linked exploitation patterns in ScadaBR to hacktivist and low‑capability actors using default credentials plus public exploit code; however, attribution is often uncertain and should be guided by forensic evidence, not assumption. Public reporting includes different assessments; defenders must be prepared for both script‑kiddy opportunism and more targeted intrusions.

---

Strategic recommendations for defenders and CISOs​

• Treat KEV entries as highest‑priority: whether you are in the federal space or a private operator, KEV additions signal active exploitation and should be triaged to the top of your vulnerability management queue. BOD 22‑01 turned this into policy for federal agencies; for non‑federal organizations the security calculus is the same.
• Harden OT exposure: eliminate direct internet access for HMIs and SCADA web UIs, implement strict network segmentation, and require a hardened jump host or bastion for administrative access. Use allowlists for management traffic and robust logging at network and host levels.
• Replace or deprecate legacy stacks: many industrial operators run outdated or unmaintained SCADA builds. If a vendor or community patch is not available, prioritize removing vulnerable instances from production networks or migrating to supported alternatives where updates and security hygiene are achievable.
• Invest in OT‑aware monitoring and incident playbooks: integrate OT assets into enterprise SIEM/EDR with OT‑specific rules, practice containment and recovery in test exercises, and maintain a clear chain of custody for forensic evidence when breaches occur.

---

Conclusion​

CISA’s addition of an OpenPLC ScadaBR vulnerability to the Known Exploited Vulnerabilities Catalog is a reminder that legacy industrial software remains a favored target for opportunistic attackers. The underlying flaw—unrestricted upload and execution of JSP files via the view_edit.shtm handler—creates a direct path to remote code execution for authenticated users and is especially dangerous in environments where management interfaces are reachable or credentials are weak.
Organizations operating ScadaBR or related stacks must treat this KEV entry with urgency: confirm whether the CVE in question matches installed versions, apply vendor/community patches or mitigations immediately, harden and segment HMI access, hunt for indicators of compromise, and follow BOD 22‑01 remediation expectations if you are a federal agency. The presence of public PoCs and observed exploitation in the wild elevates the threat—fast, coordinated action now will close the attack window and reduce the operational and safety risks to industrial environments.

---

Source: CISA CISA Adds One Known Exploited Vulnerability to Catalog | CISA