When files are uploaded into dotCMS via the content API, but before they become content, dotCMS writes the file down in a temp directory.  In the case of this vulnerability, dotCMS does not sanitize the filename passed in via the multipart request header and thus does not sanitize the temp file's name.  This allows a specially crafted request to POST files to dotCMS via the ContentResource (POST /api/content)  that get written outside of the dotCMS temp directory.  In the case of this exploit, an attacker can upload a special .jsp file to the webapp/ROOT directory of dotCMS which can allow for remote code execution.

Additionally, if dotCMS is configured withCONTENT_APIS_ALLOW_ANONYMOUS=WRITE then this vulnerability is exploitable by Anonymous users.

Upgrade

The recommended way to mitigate the issue is upgrade to dotCMS versions that contain code fixes for the issue.   This includes versions 22.03, 5.3.8.10_lts and/or 21.06.7_lts.   

Hotfix Plugins

If an upgrade is not possible, we have developed OSGI based plugins that can be deployed in your dotCMS environments.

dotCMS 5.1.6+

We have developed an osgi plugin that can be used to mitigate the issue in running dotCMS instances.  This plugin is designed to work with versions dotCMS 5.1.6 and higher and can be found here:
https://github.com/dotCMS/patches-hotfixes/tree/master/com.dotcms.security.multipartrequest

dotCMS (4.x-5.1.5)

For users running older, unsupported versions of dotCMS ( 4.x-5.x) a version of the plugin has also been developed. This plugin should provide the same protections as the above plugin though we would suggest validating this plugin in your environments.
https://github.com/dotCMS/patches-hotfixes/tree/v.4.x/com.dotcms.security.multipartrequest

dotCMS (<4.x)
For users running unsupported versions of dotCMS before version 4.0, there does not seem to be an impact from this vulnerability. We cannot 100% guarantee that this vulnerability does not exist in versions of dotCMS outside of their support lifetime, the same tests used to confirm the vulnerability in 4.0+ did not work against earlier versions of dotCMS.

WAF

On some WAF frameworks, the vulnerability can be mitigated by enabling rules that prohibit path traversal requests.  For example, AWS WAF has a ruleset : GenericLFI_BODY which

Inspects for the presence of Local File Inclusion (LFI) exploits in the 
request body. Examples include path traversal attempts using techniques like ../../.

Label: awswaf:managed:aws:core-rule-set:GenericLFI_Body

Such a ruleset can cause side effect issues, like preventing files that include relative paths from being uploaded.  Regardless, such a rule is effective in a production/delivery only environment. 

Disable Anonymous Content Submittal

While not a complete mitigation, if you are not using anonymous content submission, e.g. dotCMS forms or front end content submission, then we recommend you set CONTENT_APIS_ALLOW_ANONYMOUS=READ or CONTENT_APIS_ALLOW_ANONYMOUS=NONE in your dotmarketing-config.properties.  Setting this prevents anonymous access to /api/content, which means an unknown attacker will not be able to exploit the vulnerability.  Note - this does not prevent a known/authenticated user from exploiting the vulnerability. 

CVE  :  CVE-2022-26352

Github Issue:
https://github.com/dotCMS/core/issues/21791

OSGi Hotfix Plugins:

• https://github.com/dotCMS/patches-hotfixes/tree/master/com.dotcms.security.multipartrequest
• https://github.com/dotCMS/patches-hotfixes/tree/v.4.x/com.dotcms.security.multipartrequest