Summary
OpenCATS contains a SQL injection vulnerability in activity DataGrid date filtering because request-controlled parameters are insufficiently validated and safely escaped. An authenticated user with access to the affected endpoints may alter database queries to read sensitive recruitment, account, contact, company, job-order, and activity data.
OpenCATS contains a SQL injection vulnerability in activity DataGrid date filtering because request-controlled parameters are insufficiently validated and safely escaped. An authenticated user with access to the affected endpoints may alter database queries to read sensitive recruitment, account, contact, company, job-order, and activity data.
Affected context
The issue occurs in OpenCATS deployments before version 0.10.0 when the home:CallsDataGrid or activity:ActivityDataGrid components process user-controlled period, startDate, and endDate parameters. Risk is present where these values influence SQL generation without strong validation, parameterization, or escaping, and where an authenticated user can reach the affected DataGrid endpoints.
The issue occurs in OpenCATS deployments before version 0.10.0 when the home:CallsDataGrid or activity:ActivityDataGrid components process user-controlled period, startDate, and endDate parameters. Risk is present where these values influence SQL generation without strong validation, parameterization, or escaping, and where an authenticated user can reach the affected DataGrid endpoints.
Exploit preconditions
- Attack surface: OpenCATS activity and calls DataGrid endpoints
- Required access: A valid authenticated OpenCATS account with access to the affected views
- Trigger point: Processing of request-controlled date-filtering parameters
- Why exploitation is possible: User-supplied values can influence SQL string comparisons and generated query logic without sufficient input validation or safe query binding
- Attack surface: OpenCATS activity and calls DataGrid endpoints
- Required access: A valid authenticated OpenCATS account with access to the affected views
- Trigger point: Processing of request-controlled date-filtering parameters
- Why exploitation is possible: User-supplied values can influence SQL string comparisons and generated query logic without sufficient input validation or safe query binding
Why this happens
The vulnerability results from constructing SQL statements with request-controlled values that are not safely separated from query syntax. Directly incorporating startDate, endDate, or related filtering logic into SQL can allow input to alter the intended query structure. This maps primarily to CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection), with insufficient input validation also relating to CWE-20.
The vulnerability results from constructing SQL statements with request-controlled values that are not safely separated from query syntax. Directly incorporating startDate, endDate, or related filtering logic into SQL can allow input to alter the intended query structure. This maps primarily to CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection), with insufficient input validation also relating to CWE-20.
Potential impact
- An attacker may read sensitive database contents
- Candidate records and contact details could be exposed
- User account, company, job-order, and activity-history data could be disclosed
- Database queries may return information outside the user's intended scope
- Further data access or modification could be possible depending on database permissions
- An attacker may read sensitive database contents
- Candidate records and contact details could be exposed
- User account, company, job-order, and activity-history data could be disclosed
- Database queries may return information outside the user's intended scope
- Further data access or modification could be possible depending on database permissions
General mitigation guidance
Mitigation generally focuses on ensuring that request parameters cannot become SQL syntax.
Common defensive patterns include:
- Use parameterized queries or prepared statements for every user-controlled value
- Apply allowlist validation for date formats, permitted periods, and supported filter values
- Keep query construction separate from request parsing and business logic
- Use secure-by-default data-access abstractions that bind parameters automatically
- Restrict database accounts to the minimum permissions required by the application
- Apply authorization checks to ensure returned records match the user's permitted scope
- Reduce trust in client-provided filters by deriving allowable ranges and identities server-side
Mitigation generally focuses on ensuring that request parameters cannot become SQL syntax.
Common defensive patterns include:
- Use parameterized queries or prepared statements for every user-controlled value
- Apply allowlist validation for date formats, permitted periods, and supported filter values
- Keep query construction separate from request parsing and business logic
- Use secure-by-default data-access abstractions that bind parameters automatically
- Restrict database accounts to the minimum permissions required by the application
- Apply authorization checks to ensure returned records match the user's permitted scope
- Reduce trust in client-provided filters by deriving allowable ranges and identities server-side
How teams detect issues like this
Organizations can identify related weaknesses through:
- Static analysis rules for SQL string concatenation involving request parameters
- Code review of DataGrid handlers and dynamic filtering functions
- Searches for unparameterized query APIs, interpolated SQL, and manual escaping
- Dynamic testing with benign invalid or boundary filter values to verify strict validation
- Database monitoring for abnormal query patterns, broad result sets, or unexpected filtering behavior
- Policy enforcement requiring prepared statements and approved data-access libraries
Automated code review and application-security testing tools can help surface unsafe query construction during development.
Organizations can identify related weaknesses through:
- Static analysis rules for SQL string concatenation involving request parameters
- Code review of DataGrid handlers and dynamic filtering functions
- Searches for unparameterized query APIs, interpolated SQL, and manual escaping
- Dynamic testing with benign invalid or boundary filter values to verify strict validation
- Database monitoring for abnormal query patterns, broad result sets, or unexpected filtering behavior
- Policy enforcement requiring prepared statements and approved data-access libraries
Automated code review and application-security testing tools can help surface unsafe query construction during development.
