Summary
SuiteCRM's document revision handler inserts a request value directly into an SQL UPDATE statement, allowing a low-privileged user with Documents module access to interfere with database queries. The issue may enable database data disclosure and unauthorized updates to linked document records; this vector does not support stacked statements or arbitrary DROP or INSERT operations.
SuiteCRM's document revision handler inserts a request value directly into an SQL UPDATE statement, allowing a low-privileged user with Documents module access to interfere with database queries. The issue may enable database data disclosure and unauthorized updates to linked document records; this vector does not support stacked statements or arbitrary DROP or INSERT operations.
Affected context
The issue occurs in GetLatestRevision.php when get_latest_for_id is interpolated into an SQL UPDATE statement. It affects SuiteCRM versions before 7.15.2 and 8.10.2. Risk depends on access to the Documents module and on the application processing the affected value through the vulnerable query path.
The issue occurs in GetLatestRevision.php when get_latest_for_id is interpolated into an SQL UPDATE statement. It affects SuiteCRM versions before 7.15.2 and 8.10.2. Risk depends on access to the Documents module and on the application processing the affected value through the vulnerable query path.
Exploit preconditions
- Attack surface: The document revision functionality in the SuiteCRM application
- Required access: A low-privileged account with Documents module access
- Trigger point: Processing
get_latest_for_idinGetLatestRevision.php - Why exploitation is possible: The input can reach the SQL statement with a literal quote despite the normal quote-encoding behavior of
securexss(), allowing SQL query structure to be altered
- Attack surface: The document revision functionality in the SuiteCRM application
- Required access: A low-privileged account with Documents module access
- Trigger point: Processing
get_latest_for_idinGetLatestRevision.php - Why exploitation is possible: The input can reach the SQL statement with a literal quote despite the normal quote-encoding behavior of
securexss(), allowing SQL query structure to be altered
Why this happens
The handler interpolates externally influenced input directly into an SQL UPDATE statement rather than treating it strictly as data. Although securexss() normally entity-encodes quotes, the described AntiXSS processing behavior can select a processed value that retains a literal quote. This is CWE-89: SQL Injection, caused by constructing a query with untrusted input instead of using parameterized database operations.
The handler interpolates externally influenced input directly into an SQL UPDATE statement rather than treating it strictly as data. Although securexss() normally entity-encodes quotes, the described AntiXSS processing behavior can select a processed value that retains a literal quote. This is CWE-89: SQL Injection, caused by constructing a query with untrusted input instead of using parameterized database operations.
Potential impact
- An attacker may disclose database data accessible through the affected query.
- An attacker could mass-update linked document records.
- The described vector does not support stacked statements or arbitrary DROP or INSERT operations.
- An attacker may disclose database data accessible through the affected query.
- An attacker could mass-update linked document records.
- The described vector does not support stacked statements or arbitrary DROP or INSERT operations.
General mitigation guidance
Defensive patterns focus on ensuring untrusted values cannot change SQL query structure:
- Use parameterized queries or prepared statements for database operations.
- Validate inputs against the expected type and format before processing.
- Treat output encoding and XSS filters as separate from SQL injection defenses.
- Apply least-privilege database permissions to limit the effects of unauthorized queries or updates.
- Restrict access to document-management functionality according to user roles.
Defensive patterns focus on ensuring untrusted values cannot change SQL query structure:
- Use parameterized queries or prepared statements for database operations.
- Validate inputs against the expected type and format before processing.
- Treat output encoding and XSS filters as separate from SQL injection defenses.
- Apply least-privilege database permissions to limit the effects of unauthorized queries or updates.
- Restrict access to document-management functionality according to user roles.
How teams detect issues like this
- Use static analysis to flag SQL statements built through string interpolation or concatenation with request-derived values.
- Review database access code for consistent use of parameterized queries and validation at trust boundaries.
- Enforce code-review or CI policies that prohibit unsafe query construction.
- Monitor for unexpected bulk changes to linked document records and unusual database access patterns.
- Use static analysis to flag SQL statements built through string interpolation or concatenation with request-derived values.
- Review database access code for consistent use of parameterized queries and validation at trust boundaries.
- Enforce code-review or CI policies that prohibit unsafe query construction.
- Monitor for unexpected bulk changes to linked document records and unusual database access patterns.
