CVE-2026-6428: Koha Library System SQL Injection Flaw

CVE-2026-6428 Overview

CVE-2026-6428 is a SQL injection vulnerability in the Koha Community integrated library system. The flaw resides in reports/catalogue_out.pl and allows an authenticated staff user holding the Reports module flag to read arbitrary data from the Koha application database. Exploitation requires the Filter URL parameter to be supplied while the Criteria parameter matches /branchcode/. The vulnerable sink concatenates the unmodified Filter value into a LIKE clause without bound parameters, enabling error-based extraction of sensitive tables. Affected data includes borrowers (password hashes, 2FA secrets, PII), borrower_password_recovery, api_keys, and sessions. The issue is tracked under [CWE-89].

Critical Impact
An authenticated low-privileged staff user can extract password hashes, 2FA secrets, API keys, and session tokens from the Koha database in a single HTTP request.

Affected Products

Koha Community Koha through 22.11.37
Koha 23.x, 24.x before 24.11.16, 25.05.x before 25.05.11
Koha 25.11.x before 25.11.05, 26.05.x before 26.05.01, and 26.11.x before 26.11.00

Discovery Timeline

2026-06-13 - CVE-2026-6428 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-6428

Vulnerability Analysis

The vulnerability is an authenticated SQL injection in the sub calculate routine of reports/catalogue_out.pl. The handler reads the Filter request parameter, replaces * with %, then appends the raw string to an auxiliary SQL statement stored in $strsth2. The resulting query is executed through DBI without parameter binding. Because the user-controlled value is interpolated inside a single-quoted LIKE clause, a quote followed by SQL syntax breaks out of the literal and continues the query.

The vulnerable concatenation appends " AND $column LIKE '$f' " to the statement using the unsanitized $f variable. An attacker can terminate the literal, append a logical conjunction, and trigger MariaDB error-based exfiltration through functions such as EXTRACTVALUE. Because DBI exceptions are rendered in the response, the database version, current user, client IP, and database name are leaked in a single request. Subsequent requests page out arbitrary rows using LIMIT n,1 combined with SUBSTRING.

Root Cause

The defective sink was introduced in commit 6bb77ae3e4 on 2008-07-09. A prior advisory, CVE-2015-4633, patched the same class of bug in sibling report scripts but did not extend the parameterization to reports/catalogue_out.pl. The root cause is direct string interpolation of an HTTP parameter into a SQL statement instead of using DBI placeholders.

Attack Vector

Exploitation requires an authenticated staff session with the Reports module flag. The attacker sends a single GET request to /cgi-bin/koha/reports/catalogue_out.pl with do_it=1, Criteria=branchcode, and a crafted Filter value containing a closing quote followed by an EXTRACTVALUE payload. The DBI exception returned in the HTML body discloses the targeted strings. Iterating the payload with LIMIT offsets enables row-by-row extraction of tables such as borrowers, api_keys, and sessions.

No synthetic exploit code is reproduced here. See the Koha Bug Report #42361 and the attached proof of concept for the full request sequence.

Detection Methods for CVE-2026-6428

Indicators of Compromise

Requests to /cgi-bin/koha/reports/catalogue_out.pl containing Criteria=branchcode together with a Filter value that includes single quotes, EXTRACTVALUE, CONCAT, 0x7e, SUBSTRING, or LIMIT tokens.
HTTP responses from catalogue_out.pl containing DBI exception strings such as DBD::mysql::st execute failed or XPATH syntax error.
Unexpected reads against the borrowers, borrower_password_recovery, api_keys, or sessions tables originating from the Koha web application user.

Detection Strategies

Inspect Apache or reverse-proxy access logs for catalogue_out.pl requests where the Filter query parameter contains SQL metacharacters or known error-based injection functions.
Enable MariaDB general or audit logging on the Koha database and alert on queries against sensitive tables issued from the report module context.
Monitor authenticated staff accounts for anomalous report generation volume or off-hours access to reports/catalogue_out.pl.

Monitoring Recommendations

Forward Koha web server logs and MariaDB audit logs to a centralized analytics platform for correlation and retention.
Create alerts that fire when DBI error strings appear in HTTP response bodies served by the Koha staff interface.
Track staff account creation, permission changes, and grants of the Reports module flag, since this permission is the precondition for exploitation.

How to Mitigate CVE-2026-6428

Immediate Actions Required

Upgrade Koha to a fixed release: 22.11.38, 24.11.16, 25.05.11, 25.11.05, 26.05.01, or 26.11.00.
Restrict the Reports module flag to a minimal set of trusted librarians and audit current assignments.
Rotate credentials and secrets that may have been exposed, including borrowers passwords, 2FA seeds, API keys, and active session tokens.

Patch Information

The Koha maintainers fixed the vulnerability by replacing the raw string concatenation in sub calculate with a parameterized placeholder bound through DBI. Fixed versions are Koha 22.11.38, 24.11.16, 25.05.11, 25.11.05, 26.05.01, and 26.11.00. Refer to the Koha Security Releases page and Koha Bug Report #42361 for upgrade guidance.

Workarounds

If immediate patching is not possible, remove the Reports module flag from all non-essential staff accounts to reduce the exploitable surface.
Deploy a web application firewall rule that blocks requests to reports/catalogue_out.pl where the Filter parameter contains single quotes or SQL keywords.
Restrict network access to the Koha staff interface (/cgi-bin/koha/) to trusted management subnets via reverse proxy ACLs.

bash

# Example reverse-proxy rule (nginx) blocking suspicious Filter payloads
location /cgi-bin/koha/reports/catalogue_out.pl {
    if ($arg_Filter ~* "('|\")|extractvalue|union|select|substring|sleep\(") {
        return 403;
    }
    proxy_pass http://koha_backend;
}