Summary
Krayin CRM before version 2.2.4 contains a blind SQL injection flaw in the leads DataGrid where user-controlled input is concatenated into a raw HAVING clause without parameter binding.
Authenticated users with access to leads can abuse the rotten_lead[in] parameter for time-based or boolean-based blind injection, potentially extracting full database contents and sensitive CRM data.
Affected context
This vulnerability occurs in Krayin CRM deployments using the affected leads DataGrid implementation where query construction relies on dynamic string concatenation.
It becomes relevant when authenticated users are permitted to filter or manipulate lead-related views and the backend uses havingRaw() or equivalent APIs without parameterized queries or robust input validation.
In such contexts, application-level filtering logic can unintentionally expose the underlying SQL structure to user-controlled expressions.
Exploit preconditions
- Attack surface: Web application interface, specifically the leads DataGrid filtering endpoint.
- Required access: Valid authenticated account with permissions to view and filter leads.
- Trigger point: Submission of crafted rotten_lead[in] parameter values that are injected into a havingRaw() clause.
- Why exploitation is possible: The application concatenates user input directly into the SQL HAVING clause without parameter binding or expression whitelisting, enabling arbitrary SQL logic evaluation through blind techniques.
Why this happens
The underlying bug is a classic instance of CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Krayin CRM constructs a HAVING clause by passing user-supplied data from the rotten_lead[in] parameter into a havingRaw() call, effectively treating input as trusted SQL syntax.
Because there is no parameterization, escaping, or constrained expression builder, attackers can inject additional operators, predicates, or subqueries that the database executes as part of the query evaluation.
This pattern reflects a broader class of insecure query-building practices where application logic uses string concatenation rather than structured query APIs, making even derived clauses like HAVING, ORDER BY, and GROUP BY susceptible to injection.
Potential impact
- Attackers may extract CRM records, including leads, contacts, and activity histories via blind SQL injection.
- Attackers could obtain user credential hashes and authentication-related metadata from the database.
- Attackers may read application configuration data stored in the database, potentially aiding further compromise.
- Attackers could manipulate query results to hide, alter, or misrepresent CRM data viewed through the application.
- In some environments, attackers may pivot to other databases or schemas reachable by the same connection.
General mitigation guidance
Effective mitigation focuses on eliminating direct string-based query construction and constraining how user input influences SQL.
Recommended defensive patterns include:
- Using parameterized queries or query builder APIs for all clauses, including WHERE, HAVING, ORDER BY, and GROUP BY.
- Treating user input as data only (e.g., filter values), never as SQL fragments or expressions.
- Applying strict whitelisting for filterable fields and operations, mapping user options to predefined query templates.
- Centralizing query-building logic so that raw SQL construction is avoided or heavily scrutinized.
- Implementing least-privilege database accounts to reduce impact if an injection path is missed.
These measures help ensure that user-supplied values cannot alter query structure, reducing both exploitability and blast radius.
How teams detect issues like this
Organizations can detect similar SQL injection risks by combining static analysis, code review, and policy enforcement:
- Configure static analysis rules to flag uses of raw SQL APIs (e.g., havingRaw(), whereRaw()) that embed variables, especially concatenated strings.
- During code review, look for dynamic query construction patterns and verify that all user input passes through parameterized bindings or validated mapping layers.
- Adopt secure coding guidelines that disallow raw SQL concatenation in application code and require justification for any exception.
- Use automated security testing tools (e.g., DAST scanners) to probe application filters and data grids for blind injection behavior, focusing on timing and boolean response differences.
- Monitor database logs for anomalous queries originating from application accounts, including unusual HAVING expressions or subqueries.
