Summary
SuiteCRM's REST v4 JSON relationship-write flow can place attacker-controlled field values into SQL statements without adequate handling. An authenticated user may exploit this to read or alter database data; file-write consequences may also be possible when the database account has elevated privileges.
SuiteCRM's REST v4 JSON relationship-write flow can place attacker-controlled field values into SQL statements without adequate handling. An authenticated user may exploit this to read or alter database data; file-write consequences may also be possible when the database account has elevated privileges.
Affected context
The issue occurs in the REST v4 JSON handler's relationship-write path. The flow reads the pre-filter RAW_REQUEST value and passes relationship data through helpers such as set_relationship, SugarRelationship::addRow(), and SugarRelationship::updateRow(), including the contact_role path. Risk depends on whether supplied values or related authorization state reach SQL construction without suitable validation and parameterization.
The issue occurs in the REST v4 JSON handler's relationship-write path. The flow reads the pre-filter RAW_REQUEST value and passes relationship data through helpers such as set_relationship, SugarRelationship::addRow(), and SugarRelationship::updateRow(), including the contact_role path. Risk depends on whether supplied values or related authorization state reach SQL construction without suitable validation and parameterization.
Exploit preconditions
- Attack surface: REST v4 JSON relationship-write operations
- Required access: An authenticated account able to invoke an affected operation
- Trigger point: Processing a relationship field during an insert or update
- Why exploitation is possible: Attacker-controlled values can reach SQL statement construction through the request and relationship helper flow
- Privilege dependency: Potential file-write impact depends on the database account's privileges
- Attack surface: REST v4 JSON relationship-write operations
- Required access: An authenticated account able to invoke an affected operation
- Trigger point: Processing a relationship field during an insert or update
- Why exploitation is possible: Attacker-controlled values can reach SQL statement construction through the request and relationship helper flow
- Privilege dependency: Potential file-write impact depends on the database account's privileges
Why this happens
The underlying issue is SQL injection, mapped to CWE-89. Relationship helper logic interpolates supplied field values into INSERT and UPDATE statements rather than consistently treating them as data through parameterized queries. Reading pre-filter request data can also leave untrusted values in the path to these security-sensitive operations.
The underlying issue is SQL injection, mapped to CWE-89. Relationship helper logic interpolates supplied field values into INSERT and UPDATE statements rather than consistently treating them as data through parameterized queries. Reading pre-filter request data can also leave untrusted values in the path to these security-sensitive operations.
Potential impact
- An attacker may read data accessible to the application's database account
- An attacker could alter database records, including relationship data
- Elevated database privileges may allow file-write consequences
- Data integrity or availability may be affected
- An attacker may read data accessible to the application's database account
- An attacker could alter database records, including relationship data
- Elevated database privileges may allow file-write consequences
- Data integrity or availability may be affected
General mitigation guidance
Mitigation generally focuses on separating SQL structure from data and reducing trust in request-derived values.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all relationship writes
- Validate and normalize values against explicit field types and allowlists
- Apply authorization checks to the target records and operations independently of request-supplied state
- Limit database-account privileges to only those required by the application
- Centralize safe query construction and avoid interpolating request values into SQL
Mitigation generally focuses on separating SQL structure from data and reducing trust in request-derived values.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all relationship writes
- Validate and normalize values against explicit field types and allowlists
- Apply authorization checks to the target records and operations independently of request-supplied state
- Limit database-account privileges to only those required by the application
- Centralize safe query construction and avoid interpolating request values into SQL
How teams detect issues like this
High-level detection approaches include:
- Static analysis for SQL strings assembled with request-derived or relationship-field values
- Code review of
RAW_REQUESThandling and paths through relationship write helpers - Checks that database operations use parameter binding consistently
- Policy enforcement that flags dynamic SQL construction in application code
- Reviewing database permissions and monitoring for unexpected query or file-operation activity
High-level detection approaches include:
- Static analysis for SQL strings assembled with request-derived or relationship-field values
- Code review of
RAW_REQUESThandling and paths through relationship write helpers - Checks that database operations use parameter binding consistently
- Policy enforcement that flags dynamic SQL construction in application code
- Reviewing database permissions and monitoring for unexpected query or file-operation activity
