CVE-2022-26352: dotCMS Unrestricted Upload of File Vulnerability
dotCMS ContentResource API contains an unrestricted upload of file with a dangerous type vulnerability that allows for directory traversal, in which the file is saved outside of the intended storage…
CVE-2022-26352 is an unrestricted file-upload flaw in the dotCMS ContentResource API that also permits directory traversal. An attacker who can reach the API can place a file of a dangerous type outside the intended storage location, which can lead to remote code execution on the host. CISA has noted known ransomware use of this vulnerability, so organizations running dotCMS should treat it as a high-priority exposure until they confirm they are patched.
How it works
The weakness combines unrestricted upload of a file with a dangerous type (related to CWE-138) with path traversal (CWE-22). The ContentResource API accepts uploaded content but does not adequately constrain the file type or the path in which the file is written. As a result, a crafted request can cause the application to save the file outside the designated content store. Once the file lands in a location from which the server or another component will execute or interpret it, the attacker can achieve remote code execution. Exact request format and payload details are not provided here; defenders should rely on the vendor advisory for technical specifics rather than public proof-of-concept material.
Am I affected? How to find it in your systems
dotCMS is a content-management platform commonly deployed as a web application or content service, often behind reverse proxies or load balancers and sometimes integrated with other enterprise systems. Inventory every instance by searching configuration management databases, container registries, virtual-machine inventories, and network service scans for hosts presenting dotCMS interfaces or known default ports and paths. Confirm the exact product edition and build against the vendor advisory; public detail on affected version ranges is limited here, so only the advisory can tell you whether a given release is vulnerable.
Review access controls and network exposure of the ContentResource API. Look for unexpected file-creation events outside normal content directories, anomalous uploads of executable or script types, and authentication or authorization failures immediately preceding such activity. Web-server, application, and host logs that record API calls to content-resource endpoints, together with file-integrity monitoring on the application and temporary directories, are useful telemetry sources. If you have endpoint detection, watch for new processes spawned from the dotCMS runtime user after suspicious upload activity.
How to remediate
Apply the updates published by the vendor exactly as described in their advisory. CISA’s required action is to apply updates per vendor instructions; that remains the primary fix. After patching, verify the ContentResource API no longer accepts unconstrained paths or dangerous file types, and re-test any custom integrations that rely on content upload.
Beyond the patch, harden the deployment for this class of flaw: run the application under a least-privilege service account, restrict write permissions on the filesystem to only the directories the application truly needs, and separate the content store from any directories that the web or application server will execute. Enforce strict allow-lists for uploaded content types at the application and reverse-proxy layers, and disable or tightly control any unused upload or content-resource endpoints.
If you can't patch immediately
Reduce exposure until the vendor update can be installed. Segment dotCMS hosts so that the ContentResource API is reachable only from trusted management or content-authoring networks; block direct internet access if it is not required. Consider temporary virtual patching or WAF rules that reject requests containing path-traversal sequences or disallowed file extensions destined for content-resource endpoints—tune and test these rules carefully to avoid breaking legitimate workflows. If the business can tolerate it, disable the affected upload functionality or place it behind additional authentication and multi-factor controls. Increase monitoring: alert on file writes outside approved content paths, on execution of newly created files by the application user, and on anomalous API usage patterns. These measures lower risk but do not replace the patch.
If your data may have been exposed
Actively exploited vulnerabilities that enable remote code execution are frequently used to establish persistence, steal data, or deploy ransomware. If you have evidence of exploitation or cannot rule it out, follow your incident-response process: isolate affected hosts, preserve logs and disk images, and assess what credentials or data the attacker could have reached. As a further check, you can run a free exposure scan of your email addresses against known breach data sets to see whether associated accounts appear in prior compromises.
AICompiled with AI assistance from public sources and published under our editorial standards.