← Blog · · df00tech

CodeIgniter4 Query Builder deleteBatch() SQL Injection Patched in v4.7.4 (CVE-2026-63221)

breaking ghsa composer CVE-2026-63221

CodeIgniter has disclosed a SQL injection vulnerability in the framework's Query Builder, tracked as CVE-2026-63221 and published via GHSA-c9w5-rwh3-7pm9. The issue carries a CVSS score of 9.4 and a public PoC is reportedly available.

What happened

According to the advisory, the Query Builder's deleteBatch() method mishandles bound values supplied through preceding where() conditions. Those bound values are substituted directly into the generated SQL with their escape flag ignored, meaning they are never escaped or quoted. If an application passes user-controlled input into where() before calling deleteBatch(), that input can be interpreted as SQL rather than as a literal value. The advisory notes this is isolated to the deleteBatch() code path — standard delete() calls correctly escape where() binds.

Why it matters

This affects any application built on codeigniter4/framework that uses deleteBatch() in combination with where() conditions built from user-controlled data — for example, bulk-delete endpoints, admin panels, or API routes that filter records for deletion by request parameters. Given the high CVSS score and public PoC, exploitation could allow attackers to read, modify, or manipulate database contents depending on the underlying DBMS and application context.

What defenders should do now

  • Upgrade to CodeIgniter4 v4.7.4 or later, per the vendor's fix.
  • Until patched, audit code for any where() calls that pass user-controlled input immediately before a deleteBatch() call, and treat those as high-priority remediation targets.
  • As an interim mitigation, strictly validate/cast values (e.g., enforce numeric IDs) before use in conditions — note this does not fully protect string-based conditions.
  • Where user-controlled conditions are required, prefer a standard delete() call with Query Builder binds instead of deleteBatch(), or express matching criteria through batch data and onConstraint() rather than a separate user-controlled where() clause.
  • From a hunting perspective, review application and database logs for anomalous DELETE statements or unexpected SQL syntax/error patterns coinciding with bulk-delete or batch API endpoints.

This is developing, same-day intel based on the vendor advisory; specifics on real-world exploitation are not yet established. See the original GitHub Security Advisory for the authoritative details: GHSA-c9w5-rwh3-7pm9.

Get new detections in your inbox

New ATT&CK coverage plus CISA KEV / CVE detection rules, roughly weekly. No spam, unsubscribe anytime.