CVE-2026-6428: SQL Injection in Koha Reports Module—Data Breach Risk

Technical summary

The SQL injection resides in reports/catalogue_out.pl, specifically in the calculate subroutine's handling of the Filter parameter when Criteria matches 'branchcode'. The vulnerable code concatenates an unfiltered $filters[0] value into a LIKE clause via string concatenation rather than prepared statements: my $f = @$filters[0]; $f =~ s/\*/%/g; $strsth2 .= " AND $column LIKE '$f' "; The resulting query is executed via Perl DBI without bound parameters, permitting error-based SQL injection (EXTRACTVALUE, updatexml, etc.). An authenticated attacker can terminate the LIKE clause with a quote and inject arbitrary SQL, including UNION-based data exfiltration, time-based blind techniques, or direct error-based leakage of database metadata and table contents. The flaw is rooted in commit 6bb77ae3e4 (2008-07-09) and was not covered by CVE-2015-4633, which patched the same vulnerability class in sibling report files. Remediation involves replacing raw concatenation with parameterized placeholders.

Business impact

Library systems using vulnerable Koha versions face high-confidence data breach risk. Attackers with staff credentials—obtained via phishing, insider threat, or compromised workstations—gain read access to the complete borrower database, including names, contact details, library card numbers, and password hashes. Theft of 2FA recovery codes, API keys, and session tokens enables lateral movement and privilege escalation within the Koha platform and potentially connected systems (e.g., SSO, self-service patron portals). For public libraries, this exposes patron privacy at scale; for academic and corporate libraries, it may trigger regulatory violations (GDPR, FERPA, CCPA). Reputational damage and incident response costs are substantial.

Affected systems

Koha Community Koha versions through 22.11.37, all 23.x versions, 24.x before 24.11.16, 25.05.x before 25.05.11, 25.11.x before 25.11.05, 26.05.x before 26.05.01, and 26.11.x before 26.11.00 are affected. Any deployment using one of these versions and running with a SQL-based backend (MySQL, MariaDB, PostgreSQL) is vulnerable if staff users exist with Reports module permissions. The flaw does not affect on-premise SQLite configurations or heavily restricted Koha instances where no staff have Reports access.

Exploitability

Exploitation requires valid staff authentication and explicit Reports module flag assignment—common in operational libraries but not trivial to obtain from the outside. However, once authenticated, no additional interaction is required; a single HTTP request to /cgi-bin/koha/reports/catalogue_out.pl with a crafted Filter parameter triggers the injection. The proof-of-concept uses EXTRACTVALUE error-based leakage to echo back database version, user, IP, and database name in the error response, confirming the flaw in seconds. Full data exfiltration can proceed using LIMIT and SUBSTRING techniques. No network segmentation or WAF bypass is needed; the Reports page is typically accessible over the internal staff interface. Skill level required is moderate—basic SQL injection knowledge suffices.

Remediation

Upgrade to Koha 22.11.38, 24.11.16, 25.05.11, 25.11.05, 26.05.01, or 26.11.00 or later, depending on your release branch. The fix replaces raw string concatenation with parameterized SQL placeholders, rendering user input inert. Administrators should prioritize patching based on the criticality of their borrower data and the number of staff users with Reports access. Until patching is complete, restrict Reports module permissions to only essential personnel and monitor access logs for suspicious catalogue_out.pl requests—particularly those containing special characters (quotes, dashes, parentheses) in the Filter or Criteria parameters.

Patch guidance

Verify your current Koha version using the version check in Koha's admin interface or the command 'perl -MKoha::Version -e 'print Koha::Version::version()'\''. If running 24.x, confirm you are on 24.11.16 or later; 25.05.x users require 25.05.11+; 25.11.x users require 25.11.05+; 26.05.x and 26.11.x have specific patch levels. Consult the Koha release notes and security bulletins to verify that your target version includes the parameterized query fix for reports/catalogue_out.pl. Test in a non-production environment first, especially if you have custom report scripts that depend on the reports module API. After upgrade, reload the Reports module and verify that existing saved reports continue to function correctly.

Detection guidance

Examine web server and application logs for HTTP requests to /cgi-bin/koha/reports/catalogue_out.pl with URL-encoded payloads in the Filter or Criteria parameters. Look for signs of SQL injection attempts: single quotes, double dashes (--), UNION keywords, EXTRACTVALUE/updatexml calls, or encoded equivalents (%27, %2d%2d). Enable query logging in MySQL/MariaDB (set global general_log=1) on your Koha database server and search for errors or unusual LIKE clauses in the logs. Monitor for rapid successive requests to catalogue_out.pl from the same staff user or IP, which may indicate automated data extraction. Review access logs for staff accounts with Reports permissions that have not historically used the Reports module.

Why prioritize this

This vulnerability earns HIGH priority (CVSS 7.6) because it combines low friction (one authenticated request), high confidentiality impact (full borrower database read), and real business consequences (privacy breach, regulatory liability). The PoC is straightforward, and the vulnerability affects multiple stable Koha releases in active use. However, it does require valid staff credentials, which slightly reduces urgency compared to unauthenticated RCE. Organizations with large patron bases, regulatory obligations, or publicly visible staff should patch within 1–2 weeks; smaller deployments may extend this to 30 days if access controls are tight.

Risk score, explained

The CVSS 3.1 score of 7.6 reflects HIGH severity: Network-accessible (AV:N), Low Attack Complexity (AC:L), and Low privilege requirement (PR:L—staff authentication). Confidentiality impact is High (C:H) due to unrestricted read access to sensitive tables; Integrity and Availability are Low (I:L, A:L) because the injection is read-focused, though UPDATE/DELETE injection is theoretically possible. The score appropriately penalizes the authentication requirement but credits the breadth and sensitivity of exposed data. In practice, risk varies by library size and data sensitivity—a small rural library may tolerate longer remediation than an academic institution or national system.

Frequently asked questions