Description

CordysCRM is an open source AI-powered customer relationship management system that supports private deployment. From 1.7.0 until 1.7.4, POST /account-pool/page allows an authenticated caller with MODULE_SETTING_UPDATE to place an arbitrary database function in SortRequest.name because CustomerPoolController.page omits Spring request validation, SortRequest.getName relies on an incomplete blacklist, and the CommonMapper.xml sort fragment inserts ${sortName} into an ORDER BY clause. Functions such as extractvalue and updatexml bypass the blacklist and can expose database values through an error oracle when the query returns at least one row. This issue is fixed in version 1.7.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.7",
  "pubDate": "2026-09-18T20:17:21.600Z",
  "pubdate": "2026-09-18T20:17:21.600Z",
  "executiveSummary": "CordysCRM versions 1.7.0 through 1.7.4 are susceptible to a SQL injection vulnerability within the /account-pool/page endpoint.\nThe vulnerability originates from improper neutralization of user-supplied data during the sorting process, which is processed via the MyBatis framework.\nAn authenticated attacker possessing the MODULE_SETTING_UPDATE permission can execute arbitrary database functions by injecting malicious payloads into the SortRequest.name parameter.\nThis vulnerability leads to information disclosure via an error-based oracle, allowing an attacker to exfiltrate sensitive data from the backend database.\nThe flaw exists because of a failure to perform adequate input validation and reliance on a deficient blacklist mechanism when handling dynamic ORDER BY clauses.\nSuccessful exploitation requires the attacker to be authenticated with specific administrative privileges. The risk is significant, as it enables unauthorized access to sensitive internal database records.\nThis issue is resolved in version 1.7.4.",
  "technicalDetails": "The vulnerability is situated within the CustomerPoolController.page method in CordysCRM, which fails to implement Spring request validation on the SortRequest object. When a POST request is sent to /account-pool/page, the application processes the SortRequest.name property for dynamic sorting.\nThe root cause is the improper handling of the ${sortName} variable within the CommonMapper.xml sort fragment. Unlike the #{} syntax in MyBatis, which uses prepared statements, the ${} syntax performs direct string interpolation, rendering the query susceptible to SQL injection.\nThe application attempts to secure this input using a blacklist; however, this mechanism is incomplete and insufficient to block advanced SQL injection techniques. Attackers can bypass these filters by utilizing database-specific error-handling functions such as extractvalue and updatexml.\nThe attack flow proceeds as follows: 1) An authenticated user with MODULE_SETTING_UPDATE privileges submits a crafted POST request to /account-pool/page. 2) The malicious input is placed into the SortRequest.name field. 3) The application forwards this unsanitized input directly into the ORDER BY clause of a SQL query defined in CommonMapper.xml. 4) The database engine executes the injected function during the sorting operation.\nBecause the system generates an error message when the query returns at least one row, attackers can leverage these functions to construct an error oracle. By crafting payloads that trigger intentional database errors (e.g., xpath syntax errors in extractvalue), the attacker can force the database to reveal the results of subqueries or internal data values within the error message returned to the user.\nThe vulnerability exists in CordysCRM versions 1.7.0 up to and including 1.7.4. It is accessible over the network to any user who has obtained the necessary MODULE_SETTING_UPDATE role, enabling them to systematically enumerate or extract data from the underlying database instance."
}