CVE-2026-6428: SQL Injection Vulnerability in Koha

What the vulnerability does

The NVD record states that exploitation allows an authenticated staff user to read arbitrary data from the Koha application database. The documented impact is confidentiality-focused rather than destructive, but the data at risk is highly sensitive. NVD specifically mentions exposure of data from tables such as borrowers, borrower_password_recovery, api_keys, and sessions.

That matters because even “read-only” SQL injection can lead to follow-on compromise. If an attacker can retrieve password hashes, 2FA secrets, password recovery data, API keys, or session records, they may be able to escalate access, hijack active sessions, crack credentials offline, or pivot into adjacent systems. In library environments holding patron information, the privacy and compliance consequences can be significant even without direct database modification.

Affected versions and fixed releases

The affected version ranges, based on the NVD record and Koha bug tracker metadata, are as follows:

Two practical details deserve attention. First, the vulnerable scope includes "through 22.11.37", "23.x", "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". Second, although 23.x is explicitly listed as affected, the retrieved bug metadata did not show a corresponding fixed 23.x release. In the absence of a visible fixed 23.x branch from the supplied sources, defenders should assume 23.x is vulnerable and plan migration to a supported fixed branch rather than waiting for a backport that may never arrive.

Exploitation status

At the time of lookup, there was no evidence in the provided primary sources confirming exploitation in the wild. The CVE was not listed in CISA’s Known Exploited Vulnerabilities catalog, and no KEV dateAdded or required federal remediation date applies based on the retrieved data. That does not prove safety; it only means no authoritative public confirmation was available from the sources used here.

A proof of concept does exist in public documentation. The NVD entry itself includes a concrete HTTP request demonstrating error-based SQL injection using EXTRACTVALUE. Because the PoC is embedded in a high-visibility public advisory, defenders should assume that reproducing exploitation is straightforward for anyone with access to a valid Koha staff session and appropriate permissions.

Technical Notes

The NVD-provided example request is:

GET /cgi-bin/koha/reports/catalogue_out.pl?do_it=1&output=screen&Limit=10&Criteria=branchcode&Filter=x'+AND+EXTRACTVALUE(1,CONCAT(0x7e,VERSION(),0x7c,USER(),0x7c,DATABASE(),0x7e))--+-
Cookie: CGISESSID=<LIBRARIAN_SESSION>

This payload is useful to defenders because it also highlights likely detection artifacts: the request targets catalogue_out.pl, uses Criteria=branchcode, and contains SQL metacharacters and functions inside Filter.

Root cause and technical details

The root cause is classic unsafe SQL construction. Per the NVD description, Koha took the first filter value, replaced * with %, and then concatenated the result directly into a SQL LIKE clause. The vulnerable code path is described as:

my $f = @$filters[0];
$f =~ s/\*/%/g;
$strsth2 .= " AND $column LIKE '$f' ";

That pattern is dangerous because user input reaches a SQL execution sink without parameter binding. The presence of a LIKE clause does not make the query safe; if quotes and SQL operators are accepted, the attacker can break out of the string and inject additional expressions. NVD notes error-based extraction via EXTRACTVALUE, which is consistent with exploiting a string-concatenated SQL expression against a backend that returns useful database errors.

The Koha patch also shows the remediation went beyond simple parameterization. The fix reportedly validates Limit as numeric, constrains Criteria to expected values such as homebranch or itype, validates Filter against known library or item-type records, and switches query execution to a bound parameter model. That layered change is important because it reduces both the immediate SQL injection sink and the broader attack surface around untrusted reporting input.

Technical Notes

The fixed pattern replaces string interpolation with bind parameters:

$strsth2 .= " AND $column LIKE ? ";
push( @bind, $f );
$sth2->execute(@bind);

The patch reportedly also introduces validation using Koha objects such as:

use Koha::Libraries;
use Koha::ItemTypes;

For secure code review, that combination tells you what to look for elsewhere in Koha customizations: request parameters reaching SQL fragments, report helpers building dynamic conditions, and any DBI execute path that is not using placeholders and bind arrays.

What defenders should do next

Start by inventorying every Koha instance and mapping each one to the quoted affected ranges. Confirm whether any system is "through 22.11.37", "23.x", "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", or "26.11.x before 26.11.00". Then identify users with Reports access and review whether that permission is broader than operationally necessary.

Next, hunt for evidence of abuse using the detection patterns above, especially requests that include Criteria=branchcode and suspicious Filter payloads. Because a public PoC exists but confirmed in-the-wild exploitation was not established in the provided sources, the right operational stance is “assume exploitability, verify exposure, and patch urgently.” This is especially true if your Koha environment contains patron PII, staff credentials, API integrations, or session records that would materially increase downstream impact.

For further reading on related vulnerabilities, check out our articles on CVE-2026-45631 and 2026-04-19 Digest on Browser Zero-Day Exploitation.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you. ```