CVE-2026-41453: Krayin CRM Blind SQL Injection Vulnerability

CVE-2026-41453 Overview

CVE-2026-41453 is a blind SQL injection vulnerability [CWE-89] in Krayin CRM versions prior to 2.2.4. The flaw resides in the leads DataGrid component, specifically inside LeadDataGrid.php. The application concatenates the rotten_lead[in] query parameter directly into a havingRaw() call without parameterized binding. Authenticated users with access to the leads module can inject arbitrary SQL into the HAVING clause. Attackers can use time-based and boolean-based blind injection techniques to enumerate the entire database, including user credential hashes, CRM records, and application configuration data.

Critical Impact
Authenticated attackers can extract the full database contents of a Krayin CRM instance, including hashed credentials and sensitive customer data, through blind SQL injection.

Affected Products

Krayin CRM (laravel-crm) versions prior to 2.2.4
Component: packages/Webkul/Admin/src/DataGrids/Lead/LeadDataGrid.php
Fixed release: Krayin CRM v2.2.4

Discovery Timeline

2026-08-03 - CVE-2026-41453 published to NVD
2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-41453

Vulnerability Analysis

The vulnerability lives in the leads DataGrid filter logic. When a user applies a rotten_lead filter, the application reads request()->input('rotten_lead.in') and appends it directly to a raw SQL fragment. The fragment is passed to Laravel's havingRaw() method without a parameter binding array. This turns the HAVING clause into a direct injection point controlled by an authenticated user.

Because the query is executed server-side and results are aggregated into a grid view, exploitation is blind. Attackers rely on conditional response timing or boolean truthiness to infer data one bit at a time. The bug is reachable by any authenticated account with permission to view the leads listing, which typically includes sales, marketing, and low-tier CRM roles.

Successful exploitation compromises confidentiality, integrity, and availability of the underlying database. Extracted credential hashes can be cracked offline, enabling follow-on account takeover across the CRM and any single-sign-on integrations.

Root Cause

The root cause is unsafe string concatenation into a havingRaw() clause combined with missing input validation on a query parameter expected to be an integer. Laravel's havingRaw() supports parameter bindings, but the vulnerable code path omitted them. The parameter rotten_lead[in] was trusted as-is and never cast to an integer before being placed into the SQL statement.

Attack Vector

An authenticated attacker with leads access sends a crafted HTTP request to the leads DataGrid endpoint. The rotten_lead[in] parameter carries an SQL payload that manipulates the HAVING clause. Time-based payloads use SLEEP() or equivalent database delay primitives, while boolean-based payloads observe presence or absence of rows in the grid response. No user interaction is required beyond the attacker's own session.

php

// Source: https://github.com/krayin/laravel-crm/commit/2a3724cb7e9e65ab98f2b42c8ca2c98dede48f62
// packages/Webkul/Admin/src/DataGrids/Lead/LeadDataGrid.php
// Patch diff — removed line is the vulnerable pattern; added lines are the fix.

        if (! is_null(request()->input('rotten_lead.in'))) {
-           $queryBuilder->havingRaw($tablePrefix.'rotten_lead = '.request()->input('rotten_lead.in'));
+           $queryBuilder->havingRaw($tablePrefix.'rotten_lead = ?', [
+               (int) request()->input('rotten_lead.in'),
+           ]);
        }

        $this->addFilter('id', 'leads.id');

The fix replaces string concatenation with a parameterized placeholder and explicitly casts the input to an integer. See the GitHub commit and the Jiva Security CVE Analysis for additional technical detail.

Detection Methods for CVE-2026-41453

Indicators of Compromise

HTTP requests to the leads DataGrid endpoint containing rotten_lead[in] values that are not simple integers.
Query parameter payloads containing SQL keywords such as SLEEP, BENCHMARK, UNION, SELECT, CASE WHEN, or comment sequences like -- and /*.
Repeated leads listing requests from the same session within short intervals, consistent with automated blind injection tooling.
Anomalous database query latency correlated with authenticated CRM sessions.

Detection Strategies

Enable web server and application access logging on the Krayin CRM host and search for rotten_lead parameters containing non-numeric characters.
Deploy a web application firewall rule that rejects rotten_lead[in] values failing an integer validation check.
Enable MySQL or MariaDB general query logging in staging environments and hunt for HAVING clauses containing sleep or conditional payloads.
Correlate authenticated user IDs with abnormal request volume against the leads endpoint.

Monitoring Recommendations

Monitor for outbound authentication attempts using credentials that match hashes stored in the CRM database, which may indicate offline cracking success.
Alert on new administrator accounts, permission changes, or password resets in Krayin CRM following suspicious leads DataGrid activity.
Track database query duration percentiles for the leads listing query and alert on sustained increases.

How to Mitigate CVE-2026-41453

Immediate Actions Required

Upgrade Krayin CRM to version 2.2.4 or later, which contains the parameterized havingRaw() fix.
Rotate all Krayin CRM user passwords and API tokens if the pre-patch version was exposed to untrusted authenticated users.
Review CRM user role assignments and remove leads access from accounts that do not require it.
Audit database accounts used by the CRM and restrict them to least-privilege permissions.

Patch Information

The official fix ships in Krayin CRM v2.2.4. The relevant change replaces the vulnerable string concatenation in LeadDataGrid.php with a parameterized query binding and integer cast. See the GitHub Release v2.2.4 and the VulnCheck Advisory for release notes and advisory context.

Workarounds

If immediate patching is not possible, place a reverse proxy or WAF rule in front of Krayin CRM that rejects requests where rotten_lead[in] is not a strict integer.
Temporarily restrict access to the leads module to trusted administrative accounts only until the upgrade is applied.
Isolate the CRM database on a dedicated account with no cross-schema privileges to limit blast radius during blind extraction attempts.

bash

# Example nginx rule to block non-integer rotten_lead[in] values
if ($arg_rotten_lead__in !~ "^[0-9]+$") {
    return 400;
}

# Upgrade command for Composer-managed deployments
composer require krayin/laravel-crm:^2.2.4
php artisan migrate --force
php artisan config:clear