|Requires Admin Access:||No|
|Fix Version:||22.03, 188.8.131.52, 21.06.7|
|Credit:||Shubham Shah - email@example.com|
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 with
The recommended way to mitigate the issue is upgrade to dotCMS versions that contain code fixes for the issue. This includes versions 22.03, 184.108.40.206_lts and/or 21.06.7_lts.
If an upgrade is not possible, we have developed OSGI based plugins that can be deployed in your dotCMS environments.
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:
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.
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
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
OSGi Hotfix Plugins: