How do you patch or mitigate CVE-2022-26352 (dotCMS Unrestricted Upload of File)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

CISA's required action for CVE-2022-26352 is to apply updates per vendor instructions. In practice, find every instance of dotCMS dotCMS in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What patching CVE-2022-26352 should look like in practice

Because this is an exploited unrestricted upload flaw, the first job is not just “apply a patch”, it is to make sure the vulnerable dotCMS instance is actually identified, reachable only by the right people, and then updated using the vendor’s instructions. The safest path is to treat the vendor advisory and the CISA KEV record as the authoritative sources for the exact remediation sequence.

For organisations that need a broader response pattern for actively exploited vulnerabilities, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is a useful operating model because it ties KEV triage, emergency mitigation, hotpatching, and post-patch hunting together.

CISA Known Exploited Vulnerabilities Catalog and the CVE Program help you validate that you are responding to the correct record and the right remediation urgency, while NIST National Vulnerability Database is the place to confirm the canonical record details and related references.

Why unrestricted upload on dotCMS is dangerous before and after patching

An unrestricted upload issue is dangerous because the initial abuse is often simple, but the downstream outcome can be serious: attackers may place a web shell, stage malicious content, or plant a file that leads to code execution or persistent access. In a public-facing CMS, the upload path itself becomes a trust boundary, so exposure on the internet materially increases the chance of exploitation before you can finish remediation.

NHIMG’s File Upload Security Guide covers the control patterns that matter here, including type and content validation, storage isolation, and malware scanning, which are the same defensive ideas that reduce the impact of unrestricted upload flaws in general.

Failure mechanism: The application accepts attacker-controlled files without enough validation or isolation, so a crafted upload can be stored or interpreted in a way that changes server-side behaviour.

Impact: The result can be defacement, malware placement, remote code execution, or a foothold that survives even after the vulnerable version is fixed if the uploaded artefact remains in place.

What to verify during cleanup and post-patch review

Patching closes the primary weakness, but it does not prove the system was not already abused. You should review upload directories, application logs, reverse-proxy logs, and any web-accessible storage for suspicious filenames, unexpected file types, recently modified content, and requests that indicate an uploaded payload was executed or fetched.

If the upload path was exposed long enough for attackers to reach it, use the same discipline you would for any exploited software weakness: verify whether malicious content was stored, whether access logs show retrieval, and whether any credentials, sessions, or service tokens were reachable from the compromised application context. NHIMG’s Vulnerability Management Guide is useful here because it frames verification, exceptions, and remediation as part of the response, not as an afterthought.

If you need a second source of practitioner guidance on exploiting upload paths, the CWE entry for unrestricted upload of file with dangerous type is the underlying weakness pattern to keep in mind when you inspect the app for adjacent validation failures.

Risk and Threat Considerations

Unrestricted upload flaws are attractive because they often let an attacker move from a simple application bug to persistent server-side control, especially when the uploaded object lands in a web-accessible location or is processed automatically by the application. In a CMS, the practical danger is not just initial compromise, but the ability to keep returning through planted content or a secondary payload.

Failure mechanism: The attacker abuses a file-upload pathway that does not sufficiently constrain file type, file handling, or storage location, then uses the uploaded artefact to execute code, stage malware, or establish persistence.

Impact: A successful exploit can turn a public CMS into an ingress point for defacement, data theft, lateral movement, or broader compromise of the hosting environment.

Standards & Framework Alignment

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

OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes coordinated vulnerability remediation central.
Recommendation — Prioritise and verify remediation for the vulnerable dotCMS instance.
OWASP ASVS	V5 — File Handling	The issue is an unrestricted file upload weakness in application file handling.
Recommendation — Harden upload validation, storage, and execution handling for file uploads.
NIST CSF 2.0	PR.DS-01 — Data-at-rest is protected	Uploaded content and stored payloads must be protected from misuse after exploitation.
Recommendation — Protect stored upload content and isolate it from executable paths.
OWASP API Security Top 10	API8 Security Misconfiguration — Security Misconfiguration	Exposed upload endpoints and unsafe server handling often stem from misconfiguration.
Recommendation — Review exposed endpoints and server handling that make uploads reachable.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The flaw is exploited through the public-facing CMS entry point.
Recommendation — Map exposure and hunt for exploitation through the public application surface.

Practitioner Guidance

What to prioritise: Patch the exposed dotCMS instance first, then immediately check whether the product is internet-facing and whether there are multiple deployments sharing the same exposure pattern. If patching is delayed, reduce exposure by removing public reachability or taking the service out of use until remediation is complete.

What to verify: Confirm that the vendor update or documented mitigation has actually been applied to every instance, including lab, staging, and forgotten internet-facing systems. Afterward, verify that no suspicious uploads remain in application storage, no unexpected executable content is present, and no web requests indicate prior exploitation.

Practitioner takeaway: For an exploited upload flaw, the operational question is not “did we patch?” but “did we close the path, remove any planted content, and prove the application was not already used as an entry point?”

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org