Summary
SuiteCRM's legacy REST methods insufficiently validate query parameters before using them as SQL WHERE clauses. An authenticated caller with list permission on a module may bypass the user_hash filter and access database data, potentially including password hashes.
SuiteCRM's legacy REST methods insufficiently validate query parameters before using them as SQL WHERE clauses. An authenticated caller with list permission on a module may bypass the user_hash filter and access database data, potentially including password hashes.
Affected context
The issue affects legacy REST methods reached through /service/v4_1/rest.php, including get_entry_list, get_entries_count, and query. It becomes risky when an authenticated caller can supply query data or authorization state that is incorporated into a security-sensitive SQL operation without sufficient structural validation.
The issue affects legacy REST methods reached through /service/v4_1/rest.php, including get_entry_list, get_entries_count, and query. It becomes risky when an authenticated caller can supply query data or authorization state that is incorporated into a security-sensitive SQL operation without sufficient structural validation.
Exploit preconditions
- Attack surface: The legacy SuiteCRM REST API at
/service/v4_1/rest.php - Required access: An authenticated account with list permission on a module
- Trigger point: Affected REST methods that use caller-controlled query parameters
- Why exploitation is possible: Insufficient structural validation allows the supplied query to affect the SQL WHERE clause and bypass the
user_hashfilter
- Attack surface: The legacy SuiteCRM REST API at
/service/v4_1/rest.php - Required access: An authenticated account with list permission on a module
- Trigger point: Affected REST methods that use caller-controlled query parameters
- Why exploitation is possible: Insufficient structural validation allows the supplied query to affect the SQL WHERE clause and bypass the
user_hashfilter
Why this happens
The affected methods incorporate caller-controlled query data into SQL conditions after insufficient structural validation. This is a SQL injection issue (CWE-89) and is also related to CWE-943, which covers improper neutralization of special elements in data query logic. The insecure pattern is allowing untrusted input to shape a security-sensitive database query rather than constraining it to an expected structure.
The affected methods incorporate caller-controlled query data into SQL conditions after insufficient structural validation. This is a SQL injection issue (CWE-89) and is also related to CWE-943, which covers improper neutralization of special elements in data query logic. The insecure pattern is allowing untrusted input to shape a security-sensitive database query rather than constraining it to an expected structure.
Potential impact
- An attacker may bypass record-level filtering and access data outside their intended scope.
- Password hashes and other database information could be disclosed.
- Recovered administrative credentials could be used to compromise the application.
- An attacker may bypass record-level filtering and access data outside their intended scope.
- Password hashes and other database information could be disclosed.
- Recovered administrative credentials could be used to compromise the application.
General mitigation guidance
Mitigations generally focus on separating data from query structure and preserving authorization checks.
- Use parameterized queries or other APIs that keep caller input from changing SQL syntax.
- Validate query inputs against a strict, documented schema and reject unexpected structures.
- Apply authorization and record-visibility constraints independently of caller-provided query conditions.
- Limit API accounts to the minimum module permissions they need, and avoid exposing sensitive fields unnecessarily.
Mitigations generally focus on separating data from query structure and preserving authorization checks.
- Use parameterized queries or other APIs that keep caller input from changing SQL syntax.
- Validate query inputs against a strict, documented schema and reject unexpected structures.
- Apply authorization and record-visibility constraints independently of caller-provided query conditions.
- Limit API accounts to the minimum module permissions they need, and avoid exposing sensitive fields unnecessarily.
How teams detect issues like this
Review REST handlers and database access code for caller-controlled values that are concatenated into SQL or used to construct WHERE clauses. Check that authorization filters cannot be altered or omitted by query parameters, and use static analysis rules to flag unsafe query construction. Policy checks can also require parameterized database access and tests that verify record-level access controls across affected methods.
Review REST handlers and database access code for caller-controlled values that are concatenated into SQL or used to construct WHERE clauses. Check that authorization filters cannot be altered or omitted by query parameters, and use static analysis rules to flag unsafe query construction. Policy checks can also require parameterized database access and tests that verify record-level access controls across affected methods.
