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
System->Maintenance-> Log Files in dotCMS dashboard is providing the username/password for database connections in the log output. Nevertheless, this is a moderate issue as it requires a backend admin as well as that dbs are locked down by environment.
OWASP Top 10 - A05) Insecure Design
OWASP Top 10 - A05) Security Misconfiguration
OWASP Top 10 - A09) Security Logging and Monitoring Failure
In dotCMS dashboard, the Tools and Log Files tabs under System → Maintenance Portlet, which is and always has been an Admin portlet, is accessible to anyone with that portlet and not just to CMS Admins. Users that get site admin but not a system admin, should not have access to the System Maintenance → Tools portlet. This would share database username and password under Log Files and download DB Dump and other dotCMS Content under Tools. Nothing in the System → Maintenance should be displayed for users with site admin role. Only system admins must have access to System Maintenance.
OWASP Top 10 - A01) Broken Access Control
OWASP Top 10 - A04) Insecure Design
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+
In dotCMS 5.x-22.06, it is possible to call the TempResource multiple times, each time requesting the dotCMS server to download a large file. If done repeatedly, this will result in Tomcat request-thread exhaustion and ultimately a denial of any other requests.
In dotCMS 5.x-22.06, TempFileAPI allows a user to create a temporary file based on a passed in URL, while attempting to block any SSRF access to local IP addresses or private subnets. In resolving this URL, the TempFileAPI follows any 302 redirects that the remote URL returns. Because there is no re-validation of the redirect URL, the TempFileAPI can be used to return data from those local/private hosts that should not be accessible remotely.
An issue was discovered in dotCMS core 5.3.8.5 through 5.3.8.15 and 21.03 through 22.10.1. A cryptographically insecure random generation algorithm for password-reset token generation leads to account takeover.
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.
dotCMS before 22.06 allows remote attackers to bypass intended access control and obtain sensitive information by using a semicolon in a URL to introduce a matrix parameter. (This is also fixed in 5.3.8.12, 21.06.9, and 22.03.2 for LTS users.) Some Java application frameworks, including those used by Spring or Tomcat, allow the use of matrix parameters: these are URI parameters separated by semicolons. Through precise semicolon placement in a URI, it is possible to exploit this feature to avoid dotCMS's path-based XSS prevention (such as "require login" filters), and consequently access restricted resources. For example, an attacker could place a semicolon immediately before a / character that separates elements of a filesystem path. This could reveal file content that is ordinarily only visible to signed-in users. This issue can be chained with other exploit code to achieve XSS attacks against dotCMS.
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