CVE-2021-26828

What it actually does

This vulnerability allows a remote authenticated user to upload a file of a dangerous type, specifically a JSP file, through the ScadaBR view editing function at view_edit.shtm. Because JSP files can execute server-side Java code when served by the underlying application container, the attacker can turn an upload capability into remote code execution. Successful exploitation can allow command execution in the context of the ScadaBR/Tomcat service account, enabling access to application data, modification of SCADA configuration, persistence through web shells, and potential pivoting to connected operational technology or adjacent systems.

Why it matters to the business

A compromised ScadaBR deployment can give an attacker the ability to alter monitoring views, disrupt industrial monitoring workflows, access sensitive operational data, and potentially interfere with automation or control-adjacent processes. The issue is listed in CISA KEV with a remediation due date of 2025-12-24, indicating confirmed exploitation in the wild and requiring urgent prioritization for exposed or operationally important deployments. Because ScadaBR is used in industrial and automation environments, exploitation may have consequences beyond IT systems, including downtime, safety concerns, loss of visibility, and emergency operational response costs.

How an attack unfolds

An attacker first obtains valid credentials for a ScadaBR instance, typically through credential theft, default or weak passwords, reuse from another breach, or prior compromise. After authenticating, the attacker accesses the view editing functionality exposed through view_edit.shtm and uploads a malicious JSP file instead of a benign view-related asset. If the application stores the uploaded JSP in a web-accessible location and the application server processes it, the attacker requests the uploaded JSP over HTTP to execute server-side code. That JSP can act as a web shell, allowing the attacker to run operating system commands, enumerate files and configuration, harvest credentials, modify SCADA-related application data, deploy additional payloads, and maintain persistence. Since this vulnerability is known to be exploited in the wild, defenders should assume attackers may use commodity web shell techniques and follow-on hands-on-keyboard activity after the initial upload.

How to fix it

Upgrade to a vendor-supported version that removes or restricts dangerous JSP upload behavior. The provided advisory data does not list exact fixed versions, so affected organizations should consult current OpenPLC/ScadaBR project advisories and release notes before upgrading. As interim mitigation, remove internet exposure, restrict ScadaBR access to trusted management networks or VPNs, enforce strong unique credentials and MFA where supported, disable or tightly restrict view editing/upload functionality if operationally feasible, block upload and execution of JSP files, and configure the application server so uploaded content is stored outside executable web paths. Review file permissions so the ScadaBR/Tomcat service account cannot write executable content into web-accessible directories. If compromise is suspected, rebuild from trusted media rather than relying only on deleting observed JSP files.

How to confirm the fix worked

Confirm the deployed ScadaBR version is not Linux through 0.9.1 or Windows through 1.12.4 unless a verified vendor backport or mitigation is applied. Validate that authenticated users cannot upload .jsp files through view_edit.shtm and that uploaded content is not served or executed by the application container. Inspect the web root, upload directories, and Tomcat deployment directories for unauthorized JSP files. Review access controls to ensure ScadaBR is not reachable from untrusted networks. After remediation, perform a controlled negative test using a harmless JSP-like upload attempt and verify it is rejected, stored as inert content, or placed outside executable paths. Confirm logs show no successful HTTP execution of unexpected JSP files before and after the fix.

Typical attack path

1. Identify an internet-exposed or reachable OpenPLC ScadaBR instance.
2. Obtain valid ScadaBR credentials through phishing, password reuse, default credentials, brute force, or prior compromise.
3. Authenticate to the ScadaBR web interface.
4. Access the vulnerable view editing endpoint, commonly view_edit.shtm.
5. Upload a malicious JSP file through the vulnerable upload path.
6. Request the uploaded JSP file over HTTP to trigger server-side execution.
7. Use the JSP as a web shell to run commands under the application server account.
8. Enumerate configuration, credentials, host details, and network reachability.
9. Deploy persistence, additional tooling, or lateral movement mechanisms.
10. Use access to disrupt monitoring, alter data/views, exfiltrate information, or pivot further into connected environments.

How to detect it

To determine whether exploitation already occurred, review ScadaBR and web server access logs for authenticated POST requests to view_edit.shtm, especially requests with multipart file uploads or filenames ending in .jsp. Correlate those uploads with later GET requests to unusual JSP paths, HTTP 200 responses for newly created JSP files, or requests containing command-style parameters. Inspect Tomcat, Java application, catalina, localhost, and application logs for JSP compilation errors, suspicious stack traces, or web shell activity. Perform filesystem triage on ScadaBR web roots, upload directories, Tomcat webapps, work/Catalina directories, and temporary directories for recently created or modified JSP files. Check process telemetry for the Java/Tomcat service spawning shells or utilities such as sh, bash, cmd.exe, powershell.exe, curl, wget, nc, netcat, certutil.exe, whoami, ipconfig, ifconfig, or net user. Review authentication logs for unusual successful logins before the upload activity, including logins from unexpected IP addresses or at abnormal times. Because this vulnerability has been exploited in the wild, also look for post-exploitation activity such as credential dumping attempts, new local users, scheduled tasks, cron jobs, unauthorized services, outbound connections from the ScadaBR server, and unexplained changes to SCADA views or configuration.

• view_edit.shtm
• POST /view_edit.shtm
• POST /ScadaBR/view_edit.shtm
• multipart/form-data
• filename=\"*.jsp\"
• .jsp
• GET /*.jsp
• /WEB-INF/
• /webapps/
• /webapps/ScadaBR/
• /work/Catalina/
• catalina.out
• localhost_access_log
• org.apache.jasper
• JasperException
• java.lang.ProcessBuilder
• Runtime.getRuntime().exec
• cmd.exe /c
• /bin/sh -c
• powershell.exe
• certutil.exe
• wget
• curl
• nc -e
• netcat
• whoami
• ipconfig
• ifconfig
• net user
• crontab
• schtasks

What your security team should do

• Treat this as high priority because it is in CISA KEV, has active exploitation in the wild, and affects SCADA/industrial monitoring software.
• Inventory all OpenPLC ScadaBR deployments and determine whether any are Linux through 0.9.1 or Windows through 1.12.4.
• Immediately remove public internet exposure and restrict access to trusted administrative networks.
• Upgrade to a vendor-supported fixed release or apply vendor-recommended hardening if no exact fixed version is available.
• Audit all ScadaBR user accounts for weak, shared, default, stale, or unnecessary credentials.
• Search application server directories and upload locations for unexpected JSP files and recently modified web content.
• Review HTTP access logs for POST requests to view_edit.shtm and subsequent requests to newly uploaded .jsp files.
• Monitor for java, tomcat, or application server processes spawning operating system shells or administrative utilities.
• If exploitation is suspected, preserve logs and filesystem evidence, rotate credentials, rebuild affected servers, and assess connected systems for lateral movement.
• Track the CISA KEV due date of 2025-12-24 and ensure remediation or compensating controls are completed before that deadline.