The Cybersecurity and Infrastructure Security Agency on December 3 added a four-year-old flaw in the OpenPLC ScadaBR industrial control software to its Known Exploited Vulnerabilities catalog, citing confirmed active exploitation in the wild. The move forces federal agencies to patch the unrestricted file upload bug — tracked as CVE-2021-26828 — within mandated timelines, and it should trigger an immediate review for any organization running the open‑source supervisory control and data acquisition platform.

The Vulnerability at a Glance

CVE-2021-26828 is an unrestricted upload of file with dangerous type (CWE‑434) in the ScadaBR web interface. An attacker who already has authenticated access — even with low‑level credentials — can upload a malicious JSP file through the view_edit.shtm endpoint. The server executes the JSP as code, handing the attacker a web shell and full control over the application. From there, lateral movement to connected programmable logic controllers, data manipulation, or outright system compromise is just a step away.

Public advisories from 2021 listed affected versions as:

  • Linux builds up to and including 0.9.1
  • Windows builds up to and including 1.12.4

Operators should validate their exact build numbers; forks or downstream distributions may shift file paths or mitigations, but the underlying upload handler remains the core risk.

Why CISA’s Move Changes the Equation

CISA maintains the KEV catalog under Binding Operational Directive 22‑01. The agency only adds a vulnerability when there is reliable evidence of active exploitation. The December 3 alert confirms that attackers are weaponizing this ScadaBR weakness right now. For Federal Civilian Executive Branch agencies, BOD 22‑01 imposes a hard deadline: typically two weeks for a CVE added in 2025, unless the entry specifies otherwise. Private‑sector operators are not legally bound, but CISA explicitly urges them to treat KEV additions with the same urgency.

The exploitation evidence changes the calculus from “patch when convenient” to “patch immediately.” In industrial environments where patching often means scheduled outages and careful testing, the speed requirement demands a coordinated response from OT engineers and cybersecurity teams.

What the Risks Mean for Your Organization

Federal Agencies and Contractors

If you fall under FCEB or handle federal data, the directive is non‑negotiable. Check the official KEV entry for the exact remediation due date and required actions. Non‑compliance can trigger audit findings, funding consequences, and elevated risk for interconnected critical infrastructure.

Private Critical Infrastructure Operators

Even without a mandate, the stakes are high. A compromised HMI can lead to manipulated setpoints, falsified telemetry, or safety‑critical process disruptions. The fact that proof‑of‑concept code has been public since 2021 and exploitation risk scores are elevated means opportunistic scanning is almost certain. If you run ScadaBR in a production environment, assume you are a target.

Small‑ and Medium‑Sized Industrial Environments

Many smaller operators adopted OpenPLC ScadaBR because of its zero‑cost licensing and lightweight footprint. Those same shops often lack dedicated OT security staff. Default credentials, flat networks, and internet‑exposed HMIs are common. For this group, the KEV listing should be a wake‑up call to inventory every instance and harden configurations immediately.

Home Lab and Hobbyist Users

While personal ScadaBR deployments rarely face the same threat profile, the code execution vector remains real. If your lab system is internet‑accessible or shares a network with other sensitive devices, apply mitigations or unplug it until you can patch.

How We Got Here: A Four‑Year Journey to KEV

CVE-2021-26828 was disclosed in June 2021 alongside a related stored cross‑site scripting flaw (CVE‑2021-26829). Public exploits, detailed write‑ups, and demonstration videos emerged quickly, reducing the barrier for attackers. Several vulnerability trackers assigned high severity scores (CVSS 8.8) and elevated Exploit Prediction Scoring System probabilities, signaling that this was a low‑effort, high‑impact target.

Yet many OT environments lagged in patching. Legacy constraints, fear of breaking production, and the “if it isn’t broke” mindset kept vulnerable ScadaBR versions online. Evidence from incident response firms now links active exploitation to hacktivist and financially motivated groups scanning for default credentials and exposed HMIs. CISA’s KEV addition formalizes what threat hunters have seen for months: the window for pre‑exploit remediation has closed.

What to Do Now: A Practitioner’s Checklist

1. Inventory and Identify

  • Map every ScadaBR installation in your environment — note version, operating system, and network exposure. Prioritize any instance reachable from the internet or business networks.

2. Apply Vendor or Community Patches

  • Check upstream OpenPLC/ScadaBR repositories and maintained forks for fixes that remove or secure the vulnerable upload functionality. If a patch exists, test and deploy it through your OT change management process.

3. Temporary Mitigations When Patching Isn’t Possible

  • Restrict file uploads: Disable access to view_edit.shtm via web server configuration or application logic until you can patch.
  • Network segmentation: Move HMI interfaces behind firewalls and allow only trusted management subnets and jump hosts. Block all internet‑sourced traffic to the HMI port.
  • Credential hardening: Rotate all default passwords, enforce multi‑factor authentication for any administrative access, and audit user accounts for unexpected additions.
  • Isolate end‑of‑life systems: If your ScadaBR version can no longer be updated, plan for decommissioning or replace it with a supported alternative. In the interim, quarantine the system behind a strict ACL.

4. Hunt for Signs of Compromise

  • Search web server logs for POST requests to view_edit.shtm containing JSP markers like <%@ page, <% out.print, or <jsp:useBean.
  • Scan upload directories for recently modified .jsp files or unfamiliar web shells.
  • Look for anomalous user accounts created close to suspicious activity or accessed from novel IP addresses.
  • Deploy network intrusion detection signatures that flag JSP upload patterns and typical web shell behaviors; tune thresholds to match your OT traffic profile.

5. Incident Response Readiness

  • If exploitation is confirmed, isolate the affected system from OT networks immediately. Preserve forensic images, logs, and memory snapshots.
  • Rebuild compromised HMI hosts from known‑good images, change all credentials, and validate PLC logic and setpoints before reconnecting to production.
  • Notify sector‑specific information sharing and analysis centers or CISA if the incident affects federal systems or crosses critical infrastructure boundaries.

The Outlook: OT Security Under KEV’s Spotlight

CISA’s steady addition of industrial control system flaws to the KEV catalog reflects a broader shift: OT vulnerabilities are no longer treated as theoretical risks relegated to annual audits. When exploitation is confirmed, the remediation clock starts ticking
for everyone.

For ScadaBR users, the immediate priority is to close this attack vector. Longer term, the incident underscores the fragility of unmaintained open‑source SCADA stacks in production. Organizations should evaluate whether the software they rely on receives timely security updates and has a community or vendor committed to releasing fixes. If not, migration planning must become part of the security roadmap.

The KEV catalog will continue to evolve. Defenders who integrate its entries into a risk‑based vulnerability management program — and who treat a new addition as a trigger for emergency response — stand the best chance of keeping their industrial processes safe from opportunistic and targeted exploitation alike.