CVE-2017-5344 in dotCMS
Summary
by MITRE
An issue was discovered in dotCMS through 3.6.1. The findChildrenByFilter() function which is called by the web accessible path /categoriesServlet performs string interpolation and direct SQL query execution. SQL quote escaping and a keyword blacklist were implemented in a new class, SQLUtil (main/java/com/dotmarketing/common/util/SQLUtil.java), as part of the remediation of CVE-2016-8902; however, these can be overcome in the case of the q and inode parameters to the /categoriesServlet path. Overcoming these controls permits a number of blind boolean SQL injection vectors in either parameter. The /categoriesServlet web path can be accessed remotely and without authentication in a default dotCMS deployment.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2025
The vulnerability described in CVE-2017-5344 represents a critical blind boolean SQL injection flaw within the dotCMS content management system version 3.6.1 and earlier. This vulnerability exists within the findChildrenByFilter() function that processes requests through the publicly accessible web path /categoriesServlet, creating a direct attack surface for remote exploitation without requiring authentication. The flaw stems from inadequate input validation and sanitization mechanisms that fail to properly escape SQL query parameters, specifically affecting the q and inode parameters that are processed through this servlet endpoint.
The technical implementation of this vulnerability demonstrates a regression in security controls that were previously implemented to address CVE-2016-8902. While the development team introduced SQLUtil class with quote escaping mechanisms and keyword blacklisting, these protective measures prove insufficient when applied to the specific parameters within the /categoriesServlet path. The SQLUtil class, designed to prevent SQL injection through string interpolation and direct SQL query execution, contains a critical oversight that allows attackers to bypass these safeguards. This bypass occurs specifically when manipulating the q and inode parameters, which are processed without adequate validation, creating multiple blind boolean SQL injection vectors that can be exploited remotely.
The operational impact of this vulnerability is severe as it enables attackers to perform unauthorized database access and data manipulation without authentication. The default dotCMS deployment configuration makes this attack vector particularly dangerous since the /categoriesServlet endpoint is accessible to all users without requiring login credentials. Attackers can leverage this vulnerability to extract sensitive information from the database, modify content, or potentially escalate privileges within the system. The blind boolean nature of the injection means that attackers must use time-based or conditional responses to determine successful exploitation, making detection more challenging but not impossible.
This vulnerability aligns with CWE-89 which specifically addresses SQL injection flaws and demonstrates characteristics consistent with the ATT&CK technique T1071.004 for application layer protocol manipulation. The flaw represents a classic case of insecure input handling where parameter validation fails to properly sanitize user-supplied data before incorporating it into SQL queries. Organizations running dotCMS versions prior to the patched release face significant risk exposure since the vulnerability can be exploited by anyone with access to the web application, making it particularly attractive to automated scanning tools and malicious actors seeking to compromise content management systems.
Mitigation strategies for CVE-2017-5344 require immediate patching of dotCMS installations to versions that properly address the SQL injection vulnerability in the SQLUtil class. System administrators should implement network-level protections such as web application firewalls to monitor and block suspicious requests to the /categoriesServlet endpoint. Additionally, organizations should consider implementing input validation at multiple layers including application-level sanitization, parameterized queries, and regular security audits of web application components. The remediation process should include thorough testing to ensure that all parameter handling within the affected servlet functions properly validates and sanitizes input data to prevent similar issues from reoccurring in other parts of the application.