An uploaded filename is attacker input. dotCMS forgot, and got a webshell.
CVE-2022-26352 is a directory traversal in dotCMS's upload API: the filename in a multipart request wasn't sanitized, so '../' sequences let an attacker write a JSP webshell to a web-reachable directory. With anonymous content creation on, that's unauthenticated RCE.
The filename on an uploaded file is not metadata you can trust. It’s attacker-controlled input, like any other field in the request, and CVE-2022-26352 is what happens when you treat it as a safe label. The directory-traversal flaw in dotCMS’s ContentResource API let an attacker put ../ sequences in the filename of a multipart upload, and because the API used that filename to build the storage path without sanitizing it, the file landed wherever the attacker wanted, including web-reachable directories. Upload a .jsp webshell to a place the server will execute it, then request it, and that’s remote code execution. CISA added it to the Known Exploited Vulnerabilities catalog with the ransomware flag.
What the bug is
It affects dotCMS 3.0 through 22.02, fixed in 22.03 (and backports 5.3.8.10 and 21.06.7). Assetnote discovered it. The core failure is straightforward: the upload handler took the client-supplied filename and used it to determine where the file was written, without stripping or rejecting path-traversal sequences. The severity hinges on configuration. When dotCMS has anonymous content creation enabled, an unauthenticated attacker can reach the upload path, making this a clean unauthenticated RCE; otherwise it requires some level of access. As with so many of these, a feature that lets untrusted users submit content is what turns a file-handling bug into a pre-auth catastrophe.
The recurring lesson
File-upload-to-RCE via an unsanitized filename is one of the most repeated bug patterns in this catalog, appearing in everything from enterprise file-transfer software to CMS platforms to appliances. The mechanics are always the same: untrusted input (the filename or archive entry name) flows into a filesystem path, traversal sequences escape the intended directory, and the destination is a place the web server will execute. The fixes are equally well-known and worth stating plainly for anyone who handles uploads:
- Never use the client-supplied filename to build a storage path. Generate your own server-side name (a random ID), store the original name only as a display label in metadata, and decouple the two entirely.
- Canonicalize and validate the destination path. After resolving the final path, confirm it’s still inside the intended upload directory; reject anything that escapes it.
- Store uploads outside the web root, or in a location configured not to execute. A
.jsp,.php, or.aspxfile that can’t be executed where it lands is far less dangerous. Serve user files through a handler, not by direct path. - Constrain who can upload at all. “Anonymous content creation” and similar open-submission features dramatically raise the stakes; gate uploads behind authentication wherever the workflow allows.
What to do
- Patch dotCMS to 22.03 or a fixed backport. Given an actively-exploited, potentially-unauthenticated RCE, prioritize it.
- Check whether anonymous content creation is enabled, and disable it if you don’t genuinely need it; that’s the difference between authenticated and unauthenticated exploitation.
- Get the CMS admin and upload surface behind appropriate access controls, and don’t expose more of it to the internet than the public site requires.
- Assume compromise on long-exposed, unpatched instances. Public exploit code (including a Metasploit module) has been available since 2022. Hunt for unexpected
.jspfiles in web directories and the application server spawning shells.
The reframe is a single rule for anyone who accepts file uploads: the filename is input, not identity. dotCMS trusted it to build a path and got a webshell, which is the same mistake behind a long line of these bugs. Generate your own names, validate your paths, and keep uploads out of executable locations, and the next traversal attempt writes nothing useful. We flag the upload-and-traversal entries because they recur constantly, and the defense is well understood, when it’s actually applied.
Sources
Share
Related field notes
-
Drupalgeddon: when a data structure is allowed to name a function to call
Drupal's Form API lets a renderable array carry a callback, that's a feature. Drupalgeddon (CVE-2018-7602) let an attacker put their own callback in, and Drupal called it: exec, passthru, system. Powerful framework metaprogramming plus untrusted input equals RCE.
-
Sitecore CVE-2021-42237: another .NET deserialization RCE in a CMS you forgot was internet-facing
CVE-2021-42237 is an insecure-deserialization RCE in Sitecore XP. It's the same .NET deserialization footgun that keeps showing up in enterprise web apps, on a CMS that often sits forgotten but internet-facing.
-
Adobe ColdFusion has been getting popped the same ways for 15 years
The KEV catalog holds a long run of ColdFusion bugs: deserialization RCEs, access-control bypasses, and file uploads, from 2013 to 2024. Different CVEs, same handful of weaknesses. If you still run internet-facing ColdFusion, you're operating a perennial target.
One email, every weekday morning.
You're in. Check your inbox.