CVE-2021-26828 is an unrestricted upload of file with dangerous type vulnerability in OpenPLC ScadaBR. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 December 2025, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
Why this vulnerability matters in OpenPLC ScadaBR
An unrestricted file upload flaw in an industrial or operational web application is dangerous because the server may accept attacker-supplied content that was never meant to be executable, processed, or stored. In products like OpenPLC ScadaBR, that can turn a simple upload function into a path toward remote code execution, web shell placement, persistence, or tampering with operational data.
File upload weaknesses are often more severe than they first appear because the attacker does not need a complex exploit chain if the application fails to verify file type, extension, content, storage location, and execution handling together. The weakness is especially important when the platform is exposed to the internet or reachable from less trusted networks.
For background on the weakness class itself, the CWE Top 25 Guide covers unrestricted upload of file with dangerous type as a root cause weakness that repeatedly shows up in real compromises.
How organisations confirm exposure
Exposure starts with asset inventory: organisations need to know where OpenPLC ScadaBR is deployed, who owns it, and whether the upload feature is reachable from any trusted or untrusted network segment. If the application is internet-facing, the risk is higher because upload abuse can be attempted at scale without prior access.
Teams should compare their inventory against the vendor advisory and the official vulnerability record, then verify whether the affected instance is actually present in production, test, or a forgotten edge environment. When a CVE is known to be exploited in the wild, prioritisation should move from routine backlog treatment to urgent validation and remediation.
Use the official CVE Program record for the canonical identifier and the CISA Known Exploited Vulnerabilities Catalog to confirm exploitation status and track remediation urgency.
Remediation and compensating controls
The preferred response is to apply the vendor fix or mitigation as soon as possible, because upload flaws are difficult to fully contain once an attacker can place arbitrary content on the server. If immediate patching is not possible, reduce exposure by disabling the upload feature, restricting access to trusted administrative paths, tightening network reachability, and placing the application behind stronger perimeter controls.
Compensating controls should focus on preventing uploaded content from being executed or interpreted as code. That includes separating upload storage from executable locations, enforcing strict allowlists for file types and content handling, and reviewing whether the application or web server can be configured so uploaded files are never served from a script-enabled path.
For broader patch and prioritisation practice, the Vulnerability Management Guide is a useful reference for asset scoping, KEV prioritisation, verification, and exception handling.
Detection and post-patch review
Detection should look for unusual upload activity, unexpected file extensions, suspicious filenames, anomalous web requests to newly created files, and signs that the uploaded content was executed or called back from the server. If compromise is suspected, review server logs, web access logs, file integrity signals, and any process execution evidence around the upload directory.
After patching, organisations should still review for post-exploitation persistence. A dangerous upload issue can leave behind web shells, altered configuration files, or malicious jobs that survive the original vulnerability being fixed. If the system handled secrets, sessions, or service credentials, those should be reviewed and rotated as part of the recovery work.
Risk and Threat Considerations
This flaw is attractive to attackers because file upload points are often exposed, simple to probe, and capable of turning one request into durable server control. In industrial and operational software, that can create a route from web access to broader system compromise if the uploaded content can be executed or used to stage follow-on activity.
Failure mechanism: The application accepts attacker-controlled files without sufficiently validating type, handling, storage location, and execution boundaries, so a hostile upload becomes an execution or persistence primitive.
Impact: Attackers may gain remote code execution, plant web shells, tamper with operational data, or use the compromised host as a foothold for lateral movement and further disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | File upload weaknesses are application security flaws that require secure design and validation controls. |
| Recommendation — Verify upload handling, content validation, and storage isolation in the application security program. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The flaw arises from inadequate validation of attacker-supplied file input. |
| SC-7 — Boundary Protection | Exploitation depends on weak trust boundaries between external upload traffic and server execution paths. | |
| Recommendation — Validate uploaded file content and metadata before accepting it for processing or storage. Isolate upload services and block untrusted traffic from reaching executable server paths. | ||
| OWASP ASVS | V5 — File Handling | ASVS file handling requirements directly address dangerous upload behavior and storage controls. |
| V15 — Secure Coding and Architecture | The vulnerability reflects an architectural failure to segregate untrusted file input from execution paths. | |
| Recommendation — Apply file handling verification to restrict types, validate content, and prevent executable uploads. Design upload workflows so untrusted files cannot execute or influence server logic. | ||
Related resources from NHI Mgmt Group
- CVE-2021-20022 (SonicWall Email Security Unrestricted Upload of File)
- How should security teams reduce exploitation risk from unrestricted file upload flaws in embedded file managers?
- Why do unrestricted file upload flaws in web file managers so often lead to remote code execution?
- How should teams prevent a client supplied MIME type from becoming a code execution path in file upload handlers?