The "reset password" login page accepted an HTML injection via URL parameters.
This has already been rectified via patch, and as such it cannot be demonstrated via Demo site link. Those interested to see the vulnerability may spin up a http://localhost:8082/dotAdmin/#/public/login?resetEmailSent=true&resetEmail=%3Ch1%3E%3Ca%20href%3D%22https:%2F%2Fgoogle.com%22%3ECLICK%20ME%3C%2Fa%3E%3C%2Fh1%3E
This will result in a view along these lines:
* OWASP Top 10 - A03: Injection
* CVSS Score: 5.4
* AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
* https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N&... https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
In dotCMS, versions mentioned, a flaw in the NormalizationFilter does not strip double slashes (//) from URLs, potentially enabling bypasses for XSS and access controls. An example affected URL is https://demo.dotcms.com//html/portlet/ext/files/edit_text_inc.jsp , which should return a 404 response but didn't.
The oversight in the default invalid URL character list can be viewed at the provided GitHub link https://github.com/dotCMS/core/blob/master/dotCMS/src/main/java/com/dotcms/filters/NormalizationFilter.java#L37 .
To mitigate, users can block URLs with double slashes at firewalls or utilize dotCMS config variables.
Specifically, they can use the DOT_URI_NORMALIZATION_FORBIDDEN_STRINGS environmental variable to add // to the list of invalid strings.
Additionally, the DOT_URI_NORMALIZATION_FORBIDDEN_REGEX variable offers more detailed control, for instance, to block //html.* URLs.
Fix Version:23.06+, LTS 22.03.7+, LTS 23.01.4+
An issue was discovered in dotCMS core 4.x through 22.10.2. An authenticated directory traversal vulnerability in the dotCMS API can lead to Remote Code Execution.
A Reflected Cross-site scripting (XSS) issue was discovered in dotCMS Core through 22.06. This occurs in the admin portal when the configuration has XSS_PROTECTION_ENABLED=false. NOTE: the vendor disputes this because the current product behavior, in effect, has XSS_PROTECTION_ENABLED=true in all configurations
An issue was discovered in the ContentResource API in dotCMS 3.0 through 22.02. Attackers can craft a multipart form request to post a file whose filename is not initially sanitized. This allows directory traversal, in which the file is saved outside of the intended storage location. If anonymous content creation is enabled, this allows an unauthenticated attacker to upload an executable file, such as a .jsp file, that can lead to remote code execution.
dotCMS before 20.10.1 allows SQL injection, as demonstrated by the /api/v1/containers orderby parameter. The PaginatorOrdered classes that are used to paginate results of a REST endpoints do not sanitize the orderBy parameter and in some cases it is vulnerable to SQL injection attacks. A user must be an authenticated manager in the dotCMS system to exploit this vulnerability.