Summary
SuiteCRM's report query builder can incorporate a report parameter value without sufficient validation when its value type is set to "Field." An authenticated user who can save a report may exploit this behavior to read database contents, including sensitive account, token, CRM, and configuration data.
SuiteCRM's report query builder can incorporate a report parameter value without sufficient validation when its value type is set to "Field." An authenticated user who can save a report may exploit this behavior to read database contents, including sensitive account, token, CRM, and configuration data.
Affected context
The issue occurs in AOR_Report::build_report_query_where when SuiteCRM builds a report query using a report editor's parameter_value with value_type=Field. It is relevant where an authenticated user is permitted to save reports and the application processes such a report. The database connector does not permit stacked queries, so direct write-through-injection is not supported by the described issue.
The issue occurs in AOR_Report::build_report_query_where when SuiteCRM builds a report query using a report editor's parameter_value with value_type=Field. It is relevant where an authenticated user is permitted to save reports and the application processes such a report. The database connector does not permit stacked queries, so direct write-through-injection is not supported by the described issue.
Exploit preconditions
- Attack surface: SuiteCRM report query generation
- Required access: An authenticated account with permission to save a report
- Trigger point: The application builds a report query containing a field-type parameter value
- Why exploitation is possible: The parameter value is incorporated into SQL without sufficient validation, allowing SQL syntax to alter the query's intended meaning
- Attack surface: SuiteCRM report query generation
- Required access: An authenticated account with permission to save a report
- Trigger point: The application builds a report query containing a field-type parameter value
- Why exploitation is possible: The parameter value is incorporated into SQL without sufficient validation, allowing SQL syntax to alter the query's intended meaning
Why this happens
The report query builder does not adequately validate or safely bind a parameter value before incorporating it into SQL. This is a SQL injection flaw (CWE-89): data supplied through a report definition is treated as part of a query rather than being kept separate from query syntax. The insufficient validation also relates to CWE-20, Improper Input Validation.
The report query builder does not adequately validate or safely bind a parameter value before incorporating it into SQL. This is a SQL injection flaw (CWE-89): data supplied through a report definition is treated as part of a query rather than being kept separate from query syntax. The insufficient validation also relates to CWE-20, Improper Input Validation.
Potential impact
- An attacker may read sensitive data across the SuiteCRM database.
- Disclosed data could include user password hashes, OAuth2 tokens, CRM records, report definitions, and configuration data.
- Exposure of credentials or tokens could enable further unauthorized access.
- Direct database modification through stacked queries is not supported by the described connector behavior.
- An attacker may read sensitive data across the SuiteCRM database.
- Disclosed data could include user password hashes, OAuth2 tokens, CRM records, report definitions, and configuration data.
- Exposure of credentials or tokens could enable further unauthorized access.
- Direct database modification through stacked queries is not supported by the described connector behavior.
General mitigation guidance
Defensive patterns focus on keeping report values separate from SQL structure and limiting the data available to report queries:
- Use parameterized queries or prepared statements for values.
- Allowlist permitted field names and validate them against the expected schema; do not rely on escaping alone.
- Apply strict, context-aware validation to report definitions before query construction.
- Restrict report creation and editing to users who need those capabilities.
- Use least-privilege database accounts and limit access to sensitive tables and columns.
- Review and minimize the sensitive data exposed through reporting features.
Defensive patterns focus on keeping report values separate from SQL structure and limiting the data available to report queries:
- Use parameterized queries or prepared statements for values.
- Allowlist permitted field names and validate them against the expected schema; do not rely on escaping alone.
- Apply strict, context-aware validation to report definitions before query construction.
- Restrict report creation and editing to users who need those capabilities.
- Use least-privilege database accounts and limit access to sensitive tables and columns.
- Review and minimize the sensitive data exposed through reporting features.
How teams detect issues like this
- Use static analysis to identify query construction that concatenates or interpolates report-controlled values into SQL.
- Review report query paths for missing parameter binding and for field names or values accepted without schema-based allowlisting.
- Monitor database and application logs for unusual report-generated queries or unexpected access to sensitive tables.
- Enforce code review and CI policies requiring parameterized queries for database access; automated review tools can help flag risky patterns.
- Use static analysis to identify query construction that concatenates or interpolates report-controlled values into SQL.
- Review report query paths for missing parameter binding and for field names or values accepted without schema-based allowlisting.
- Monitor database and application logs for unusual report-generated queries or unexpected access to sensitive tables.
- Enforce code review and CI policies requiring parameterized queries for database access; automated review tools can help flag risky patterns.
