CVE-2026-85388 in Worklenz
Summary
by MITRE • 09/03/2026
Worklenz through 3.0.0 fails to properly validate the sort-field query parameter in pagination helper functions, allowing authenticated users to inject arbitrary PostgreSQL expressions into ORDER BY clauses. Attackers can use time-based and boolean-based blind SQL injection techniques to extract sensitive database content including password hashes from other tenants. This is an incomplete fix for CVE-2026-25947.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in Worklenz versions up to 3.0.0 represents a critical failure in input validation within the application's pagination logic, specifically concerning the sort-field query parameter. This flaw allows authenticated users to inject arbitrary PostgreSQL expressions into ORDER BY clauses used by database helper functions. Unlike standard SQL injection vectors that target data retrieval through WHERE or SELECT statements, this vulnerability exploits the structural components of the SQL query itself. By manipulating how results are sorted, an attacker can bypass typical application-level filters and directly interact with the underlying database engine to execute unintended commands. This specific type of flaw is categorized under CWE-89, which covers Improper Neutralization of Special Elements used in an SQL Command, highlighting the failure to sanitize or validate user-supplied input before its inclusion in a dynamic query structure.
The operational impact of this vulnerability extends beyond simple data exfiltration from the immediate user's context due to the nature of blind SQL injection techniques available through this vector. Attackers can leverage time-based and boolean-based methods to infer information about the database schema and contents without receiving direct error messages or result sets in the HTTP response. This capability enables the extraction of sensitive data, including password hashes belonging to other tenants within a multi-tenant architecture. The ability to access cross-tenant data indicates a severe breakdown in logical isolation mechanisms, potentially leading to widespread credential compromise across the entire platform. Such actions align with ATT&CK technique T1059.004, which describes SQL Injection as an input vector for command execution or data extraction, and specifically relate to Data from Information Repositories under the Collection phase of the attack lifecycle.
This issue is noted as an incomplete fix for CVE-2026-25947, suggesting that previous remediation efforts failed to fully address the root cause within the pagination helper functions. The persistence of this vulnerability implies that while some input validation may have been implemented, it was either bypassed by specific PostgreSQL syntax or applied only to certain code paths rather than globally across all sorting operations. This partial mitigation leaves a significant attack surface open for sophisticated adversaries who can probe for edge cases in parameter handling. The existence of such an incomplete fix underscores the necessity for comprehensive input validation strategies that cover not just explicit data fields but also structural query parameters like sort orders and pagination limits, which are often overlooked during standard security reviews.
To mitigate this vulnerability, developers must implement strict allow-listing for all values passed to sorting functions rather than relying on blacklist-based filtering or simple escaping mechanisms. Since SQL injection in ORDER BY clauses cannot be effectively mitigated using parameterized queries alone due to the syntactic requirements of database engines, explicit validation against a predefined set of acceptable column names and sort directions is required. Additionally, enforcing principle of least privilege for the database user account running the application can limit the scope of damage if an injection succeeds by restricting access to sensitive tables or functions outside the immediate tenant's data partition. Regular security audits focusing on dynamic SQL construction in helper libraries are essential to ensure that all potential vectors for structural query manipulation are identified and neutralized before deployment.