CVE-2026-63221: SQL Injection in CodeIgniter4 Query Builder deleteBatch()

The CodeIgniter4 Query Builder provides an object-oriented interface for generating database queries. A specific design pattern within web applications involves batch processing, where records are updated or deleted in groups using helper methods such as deleteBatch(). To optimize execution, these methods accept arrays of data and combine them with standard Query Builder state filters, including chained where() clauses.

The vulnerability, identified as CVE-2026-63221, resides in how these state filters are combined with the final query. When standard Query Builder filters are applied before a deleteBatch() execution, the database compiler triggers a separate compilation pipeline. Instead of binding these parameters securely or routing them through standard query parametrization interfaces, the database-specific builder classes attempt to manually compile the final SQL string.

This manual compilation leads to a vulnerability class known as improper neutralization of special elements used in an SQL command, classified under CWE-89. The query compilation logic bypasses the active database driver escaping mechanism for filters assigned via standard where clauses. As a result, user-controlled input designed to act as a data value can break out of the SQL syntax context and execute arbitrary database operations.

To understand the root cause of the flaw, it is necessary to examine how CodeIgniter's Query Builder manages parameter state. When a developer registers a condition using $builder->where('field', $value), the framework generates an internal binding entry. This entry is represented inside the $this->binds associative array, where the key represents the parameter identifier and the value is a indexed array containing two elements: the actual bound value ($bind[0]) and a boolean escape flag ($bind[1]). The escape flag indicates whether the database driver must sanitize and wrap the value in quotes prior to compilation.

In standard SQL compilation paths, such as those executed during a typical delete() or select() operation, the compiler processes this array sequentially and applies driver-specific escaping rules to any bind where the escape flag is active. However, when performing batch deletions, the compilation path diverges. The framework uses driver-specific compilers, such as the _deleteBatch() method located in the core BaseBuilder.php class, as well as dedicated files for drivers like Oracle (OCI8) and PostgreSQL.

Within these batch compilation routines, the framework merges the batch-specific constraints with any prior where conditions. In versions 4.3.0 through 4.7.3, this merge operation was handled by a nested loop that performed a direct string replacement on the query placeholders. The loop extracted the value element directly from the $this->binds array and ran str_replace on the SQL condition template. This replacement completely ignored the state of the escape flag stored in $bind[1] and did not route the raw value through the database connection's character escaping routines. Consequently, the literal unescaped string was embedded directly into the executable query.

An analysis of the vulnerable source code in system/Database/BaseBuilder.php reveals the exact point where parameter isolation fails. The following snippet illustrates the naive loop implementation before the vulnerability was patched:

// system/Database/BaseBuilder.php (Vulnerable implementation in versions < 4.7.4)
protected function _deleteBatch(string $table, array $keys, array $values): string
{
    // ... [Batch query syntax initialization] ...
 
    // convert binds in where
    foreach ($this->QBWhere as $key => $where) {
        foreach ($this->binds as $field => $bind) {
            // VULNERABILITY: Direct string replacement. $bind[0] contains the raw value.
            // $bind[1] (the escaping boolean) is completely ignored in this iteration.
            $this->QBWhere[$key]['condition'] = str_replace(':' . $field . ':', $bind[0], $where['condition']);
        }
    }
 
    $sql .= ' ' . $this->compileWhereHaving('QBWhere');
    // ...
}

The patch introduced in CodeIgniter 4.7.4 refactors this process. It introduces a dedicated helper method named convertWhereBindsForBatch() which checks the escape flag and utilizes the underlying database connection's escaping capability:

// system/Database/BaseBuilder.php (Patched implementation in version 4.7.4)
protected function _deleteBatch(string $table, array $keys, array $values): string
{
    // ...
    // convert binds in where
    // FIX: Replaced loop with a secure, centralized escaping helper
    $this->convertWhereBindsForBatch();
 
    $sql .= ' ' . $this->compileWhereHaving('QBWhere');
    // ...
}
 
/**
 * Escapes and substitutes the WHERE binds into the QBWhere conditions
 * for batch delete queries.
 */
protected function convertWhereBindsForBatch(): void
{
    $replacers = [];
 
    foreach ($this->binds as $field => $bind) {
        // FIX: The database driver escape() method is called if the escape flag ($bind[1]) is true.
        $escapedValue = $bind[1] ? $this->db->escape($bind[0]) : $bind[0];
 
        if (is_array($bind[0])) {
            $escapedValue = '(' . implode(',', $escapedValue) . ')';
        }
 
        $replacers[':' . $field . ':'] = (string) $escapedValue; // Safe string casting
    }
 
    // FIX: Using strtr() with pre-populated mapping avoids vulnerable double-replacement scenarios.
    foreach ($this->QBWhere as $key => $where) {
        $this->QBWhere[$key]['condition'] = strtr($where['condition'], $replacers);
    }
}

By delegating parameter substitution to convertWhereBindsForBatch(), the system ensures that values containing single quotes or other SQL control characters are safely formatted. For instance, single quotes are doubled up or backslash-escaped according to the specific rules of the database driver in use. Additionally, the replacement mechanism was switched from a nested loop using str_replace to a single-pass strtr function. This prevents double-substitution attacks where an attacker crafts input containing synthetic placeholders to manipulate subsequent replacement steps.

Exploitation of CVE-2026-63221 requires an endpoint that processes user input and chains it to a query builder context before a batch delete operation. A typical vulnerable pattern occurs in administrative bulk data purges or session clearouts.

Consider a target application processing request parameters to filter batch deletions:

// Example of vulnerable application logic
public function bulkDeleteLogs() 
{
    $filter = $this->request->getPost('filter_value');
    $batchData = [
        ['log_id' => 12,
         'archive_status' => 'pending'],
        ['log_id' => 13,
         'archive_status' => 'pending']
    ];
 
    $builder = $this->db->table('system_logs');
    $builder->setData($batchData, null, 'data')
            ->onConstraint(['log_id' => 'log_id'])
            ->where('log_type', $filter) // Unescaped user input
            ->deleteBatch();
}

If an attacker submits a payload structured to alter the syntax logic, the unescaped interpolation inserts the string verbatim. For instance, the attacker provides the payload ' OR 1=1 --. The Query Builder parses the where condition and compiles the target query. Because the replacement logic uses direct string substitution, the compiled SQL string outputs the following syntax:

DELETE FROM "system_logs" WHERE "system_logs"."log_type" = '' OR 1=1 --' AND "system_logs"."log_id" IN (12, 13)

When processed by the database engine, the OR 1=1 clause evaluates to true for every row in the database table. The SQL comment syntax (--) truncates the remaining constraints generated by the batch processor. As a consequence, the DBMS executes a full table deletion, removing all logs and causing a localized denial of service and loss of database integrity.

The impact of CVE-2026-63221 is rated as Critical, with a CVSS v3.1 base score of 9.4. Although the vulnerability resides within a batch delete operation rather than a select operation, the security implications are severe. The primary impact is to system integrity and availability, as unauthorized database modifications can occur without authentication.

In standard configurations, an attacker can exploit this SQL injection vulnerability to destroy arbitrary tables, manipulate administrative user tables, or bypass application constraints. Depending on the underlying database engine and the system's execution privileges, stacked query capabilities could allow the execution of secondary SQL statements. For databases like PostgreSQL or Microsoft SQL Server, this could lead to remote execution of OS commands via system functions (such as xp_cmdshell or external language bindings).

Additionally, because the vulnerability allows the injection of SQL functions, attackers can perform blind, time-based SQL injection to exfiltrate database contents. By substituting data values with conditional evaluation functions (like pg_sleep()), the attacker can read sensitive configuration keys, password hashes, or application records character-by-character based on database response delays.

The most secure remediation for this vulnerability is to upgrade the application framework to CodeIgniter version 4.7.4 or later. This release completely addresses the parsing flow in the standard query compiler and driver-specific subclasses.

If upgrading the framework is not immediately possible due to dependency constraints, you can manually apply the patch by editing the base database class. Open system/Database/BaseBuilder.php and locate the _deleteBatch method. Replace the naive foreach loop that performs the str_replace operations with the implementation of convertWhereBindsForBatch() as outlined in the patch analysis.

In addition to upgrading, developers must review applications for unsafe query builder state chaining. As a general security measure, avoid passing raw, unvalidated input directly to Query Builder state methods. Utilize strict input validation schemas (such as alphanumeric regex filters or predefined allowlists) to ensure that only expected query criteria are processed by the database compiler.