Summary
SuiteCRM contains a SQL injection flaw in Multi report conditions, where user-controlled input can reach a database query without safely handling quotes. A low-privileged user with AOR Reports access may be able to read data from arbitrary tables or affect database availability when a crafted report condition is processed.
SuiteCRM contains a SQL injection flaw in Multi report conditions, where user-controlled input can reach a database query without safely handling quotes. A low-privileged user with AOR Reports access may be able to read data from arbitrary tables or affect database availability when a crafted report condition is processed.
Affected context
The issue occurs in SuiteCRM's AOR Reports functionality when a Multi report condition is processed. Input passed through unencodeMultienum() can be concatenated into a SQL WHERE clause; under the described AntiXSS behavior, certain input can leave a literal quote unencoded. The risk depends on access to AOR Reports and on the affected code path being reached.
The issue occurs in SuiteCRM's AOR Reports functionality when a Multi report condition is processed. Input passed through unencodeMultienum() can be concatenated into a SQL WHERE clause; under the described AntiXSS behavior, certain input can leave a literal quote unencoded. The risk depends on access to AOR Reports and on the affected code path being reached.
Exploit preconditions
- Attack surface: SuiteCRM AOR Reports functionality
- Required access: A low-privileged account with AOR Reports access
- Trigger point: Processing a user-controllable Multi report condition
- Why exploitation is possible: Input can pass through decoding and sanitization behavior that leaves a quote available to alter the SQL query structure
- Attack surface: SuiteCRM AOR Reports functionality
- Required access: A low-privileged account with AOR Reports access
- Trigger point: Processing a user-controllable Multi report condition
- Why exploitation is possible: Input can pass through decoding and sanitization behavior that leaves a quote available to alter the SQL query structure
Why this happens
The application incorporates user-controlled data into a SQL WHERE clause without ensuring that it remains data rather than query syntax. In the reported flow, unencodeMultienum() processes the value, and AntiXSS may select a processed string instead of its encoded backup, allowing a quote to reach the query. This is a CWE-89: SQL Injection pattern caused by unsafe query construction.
The application incorporates user-controlled data into a SQL WHERE clause without ensuring that it remains data rather than query syntax. In the reported flow, unencodeMultienum() processes the value, and AntiXSS may select a processed string instead of its encoded backup, allowing a quote to reach the query. This is a CWE-89: SQL Injection pattern caused by unsafe query construction.
Potential impact
- Attackers may read data from database tables beyond their intended access
- Query behavior may be altered, potentially exposing sensitive CRM records
- Delay-based expressions could consume database connections and degrade availability
- Attackers may read data from database tables beyond their intended access
- Query behavior may be altered, potentially exposing sensitive CRM records
- Delay-based expressions could consume database connections and degrade availability
General mitigation guidance
Mitigation generally focuses on keeping user input separate from SQL syntax.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all user-controlled values
- Avoid concatenating decoded or sanitized input into SQL statements
- Apply strict allowlist validation for values that must follow a constrained format
- Minimize database account privileges and restrict report access to business needs
- Treat client-submitted report conditions as untrusted, regardless of prior UI validation
Mitigation generally focuses on keeping user input separate from SQL syntax.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all user-controlled values
- Avoid concatenating decoded or sanitized input into SQL statements
- Apply strict allowlist validation for values that must follow a constrained format
- Minimize database account privileges and restrict report access to business needs
- Treat client-submitted report conditions as untrusted, regardless of prior UI validation
How teams detect issues like this
Useful detection approaches include:
- Static analysis for SQL statements built through string concatenation with request or report-condition data
- Code review of decoding, sanitization, and query-construction paths, especially where values pass through multiple transformations
- Database and application monitoring for anomalous report queries, unusually long query execution, or elevated connection usage
- Policy checks that require parameterized queries for dynamic SQL
Useful detection approaches include:
- Static analysis for SQL statements built through string concatenation with request or report-condition data
- Code review of decoding, sanitization, and query-construction paths, especially where values pass through multiple transformations
- Database and application monitoring for anomalous report queries, unusually long query execution, or elevated connection usage
- Policy checks that require parameterized queries for dynamic SQL
