Is CVE-2021-26828 (OpenPLC ScadaBR Unrestricted Upload of File with Dangerous Type) being exploited in the wild?

Yes. CISA added CVE-2021-26828 to its Known Exploited Vulnerabilities catalogue on 3 December 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. OpenPLC ScadaBR contains an unrestricted upload of file with dangerous type vulnerability that allows remote authenticated users to upload and execute arbitrary JSP files via view_edit.shtm.

What “exploited in the wild” means for this CVE

For this vulnerability, the practical answer is not just that a flaw exists, but that it has reached active attacker use. Once a CVE appears in CISA’s KEV catalogue, treat it as a confirmed exploitation problem rather than a theoretical risk and prioritise it ahead of ordinary backlog items. The question is therefore about current exposure, not historical weakness alone.

The underlying issue here is an unrestricted file upload path that can let a remote authenticated user upload and execute a JSP file through the application interface. That shifts the concern from simple content upload to server-side code execution risk, so a patch or mitigation is only meaningful if the affected service is actually identified and contained in your environment.

One useful starting point is the Zero-Day and Exploited Vulnerabilities Guide, which frames how to triage KEV-listed issues, compress response time, and verify whether an exploited flaw has already left evidence behind.

How to confirm exposure and reduce immediate risk

Confirm whether OpenPLC ScadaBR is deployed, whether the vulnerable upload workflow is reachable, and whether any account with upload capability is still active. For internet-facing or externally reachable instances, assume the exploitability window is operational until you can verify version status, access boundaries, and whether the upload endpoint is exposed through a proxy, VPN, or port forward.

If patching or upgrade work cannot happen immediately, reduce risk by removing external reachability, restricting who can authenticate, and disabling the specific upload path if the product supports it. File-upload flaws are especially dangerous when web roots, execution permissions, and upload storage are not separated, because a successful upload can become executable content rather than inert data.

The File Upload Security Guide is the most direct internal reference for the control failures involved here, especially validation gaps, storage isolation, and the web shell pattern that often follows an unrestricted upload weakness.

For authoritative vulnerability records, check the CVE Program entry and the NIST National Vulnerability Database record, then compare those details with the vendor advisory and your own asset inventory before declaring the issue contained.

What to check after exposure is confirmed

Because this flaw can support arbitrary JSP execution, response should include compromise checking, not only patching. Review web server logs, application logs, upload directories, unusual JSP creation or modification, and any signs of follow-on commands launched from the ScadaBR process context. If the system accepted a malicious upload, assume the attacker may have used it for persistence or additional access rather than a one-off action.

When web content execution is possible, credential review also matters. Rotate any credentials, sessions, or service accounts that could have been used through the affected application, especially if the upload function sat behind a reused application login or shared administrative account. That is a containment step, not a substitute for hunting.

For a broader view of the prioritisation logic, Vulnerability Management Guide helps teams decide how to verify scope, track exception handling, and measure whether remediation actually reduced exposure instead of just closing a ticket.

Risk and Threat Considerations

Unrestricted upload issues are high-risk because they often convert a normal application feature into a server-side execution path. In an industrial or operational environment, that can move an attacker from application access into code execution on a system that may be trusted by other internal tools.

Failure mechanism: The attacker abuses a file-upload workflow that does not properly restrict type, destination, or execution behaviour, then uploads a server-executable JSP file and invokes it through the application path.

Impact: The likely consequence is remote code execution under the application’s privileges, which can lead to persistence, configuration tampering, data access, or lateral movement if the host is trusted elsewhere.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-16 — Application Software Security	Unrestricted file upload is an app security weakness needing secure coding and validation
Recommendation — Harden upload handling with strict validation, isolation, and safe execution defaults.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	The flaw stems from accepting dangerous file input without proper restriction
	CM-7 — Least Functionality	Disabling unnecessary upload and execution paths reduces exploitability
Recommendation — Validate uploaded content, type, and destination before it is accepted or processed. Remove or disable upload and execution features that are not operationally required.
OWASP ASVS	V5 — File Handling	The issue is a file upload control failure that ASVS file-handling requirements address
Recommendation — Apply file-handling verification to restrict type, storage, and execution of uploads.
MITRE ATT&CK	T1105 — Ingress Tool Transfer	Attackers often stage payloads by transferring files into the target environment
Recommendation — Hunt for uploaded payload staging and unexpected file transfer activity on the target.

Practitioner Guidance

What to verify: Verify whether the vulnerable service is still reachable, whether uploaded files land in an executable context, and whether any suspicious JSP or script artefacts were created after the exposure window opened. If the answer is yes to any of those, treat the issue as a compromise assessment, not just a patching exercise.

Decision rule: If the instance can accept authenticated uploads and those uploads can be executed by the web tier, prioritise containment and evidence collection before waiting for a routine maintenance cycle. If the instance is isolated and the upload path is disabled or non-executable, remediation urgency is still high, but the blast radius is narrower.

Practitioner takeaway: For KEV-listed file-upload flaws, the main decision is whether you are still in a prevention phase or already in an incident response phase, and the right answer depends on execution exposure and log evidence, not on whether exploitation has been personally observed in your environment.