CVE-2026-70370 in Koha
Summary
by MITRE • 08/04/2026
Koha's reports/catalogue_stats.pl builds dynamic SQL in sub calculate by interpolating the user-controlled Line and Column request parameters directly into identifier positions of the query (SELECT DISTINCTROW, GROUP BY, ORDER BY) with no whitelist validation. When Line contains itemcallnumber and the cotedigits parameter is truthy, cotedigits is additionally concatenated raw as the numeric argument of a LEFT() call. An authenticated staff user holding the reports module permission can inject arbitrary SQL and read any table reachable by the Koha database user, including borrowers (password hashes, two-factor secrets, personal data), api_keys, and sessions.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/04/2026
This vulnerability exists in Koha's catalogue statistics reporting module where the dynamic SQL construction process fails to properly validate or sanitize user inputs. The flaw resides in the reports/catalogue_stats.pl script which directly interpolates Line and Column request parameters into identifier positions of SQL queries without any form of input validation or sanitization. When the Line parameter contains itemcallnumber and the cotedigits parameter evaluates to truthy, the cotedigits value is additionally concatenated raw as a numeric argument within a LEFT() function call, creating an additional injection vector. The vulnerability specifically affects authenticated staff users who possess the reports module permission, making it a privilege escalation issue rather than a simple remote code execution threat. This represents a classic SQL injection vulnerability that falls under CWE-89, which describes improper neutralization of special elements used in an SQL command.
The technical implementation flaw stems from the absence of whitelist validation mechanisms for dynamic SQL identifiers. The system accepts user-provided values and directly incorporates them into query structure elements such as SELECT DISTINCTROW clauses, GROUP BY statements, and ORDER BY constructs. This approach violates fundamental security principles of input validation and parameterization. When combined with the additional LEFT() function injection through the cotedigits parameter, attackers can manipulate not just query structure but also the actual logic and data retrieval behavior of the database operations. The vulnerability enables full data access capabilities including sensitive tables that contain borrower information such as password hashes, two-factor authentication secrets, and personal identification data.
The operational impact of this vulnerability is severe and multifaceted. An authenticated attacker with reports module permissions can extract any data accessible to the Koha database user account, potentially compromising thousands of borrower records simultaneously. The exposure includes not only personal information but also security tokens, API keys, and session data that could enable further unauthorized access or persistence within the system. This vulnerability essentially provides a backdoor to the entire database infrastructure that Koha uses for library management operations. The threat model aligns with ATT&CK technique T1078 which covers valid accounts and T1213 which covers data from information repositories, as the attacker gains access to data stored in Koha's database system.
Mitigation strategies must focus on implementing proper input validation and parameterization of all dynamic SQL elements. The system should employ whitelist validation for all user-controllable identifiers used in SQL query construction, particularly for SELECT, GROUP BY, and ORDER BY clauses. All dynamic parameters must be properly escaped or parameterized before being incorporated into database queries. Additionally, privilege separation should be implemented so that the database user account used by Koha has minimal required permissions, limiting the potential damage from any successful injection attempts. The fix should also include implementing proper access controls to ensure that only authorized staff members with legitimate business needs can access sensitive reporting functions. Regular security audits and code reviews should be conducted to identify similar patterns of dynamic SQL construction that may present similar vulnerabilities in other parts of the application.