CVE-2026-70369 in Koha
Summary
by MITRE • 08/04/2026
Koha's reports/acquisitions_stats.pl builds its per-cell statistics query in sub calculate by interpolating the user-controlled Filter request parameters directly into WHERE fragments covering aqbasket.closedate, aqorders.datereceived, aqbooksellers.name, items.homebranch, items.ccode, biblioitems.itemtype, aqbudgets.budget_code, aqorders.sort1, and aqorders.sort2. The statement is prepared and executed with no bound parameters. 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), borrower_password_recovery, 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 represents a critical sql injection flaw in Koha's acquisitions statistics report functionality that stems from improper input sanitization and query construction practices. The issue occurs within the reports/acquisitions_stats.pl script where the application constructs dynamic sql queries by directly interpolating user-supplied filter parameters into where clauses without any parameter binding or input validation. This design pattern creates an environment where malicious actors can manipulate the sql execution flow by injecting crafted input into the Filter request parameters that control various database fields including basket closing dates, order receiving dates, vendor names, branch locations, item categories, budget codes, and sorting fields.
The technical exploitation of this vulnerability leverages the principle of sql injection as classified under cwe-89, where untrusted data is incorporated into sql commands without proper escaping or parameterization. Attackers with authenticated access to the reports module can construct malicious input that alters the intended sql query structure to extract sensitive information from any table accessible to the Koha database user account. This includes critical personal data such as borrower password hashes, two-factor authentication secrets, and confidential patron information stored in tables like borrowers, borrower_password_recovery, api_keys, and sessions. The vulnerability exists because the application employs a dangerous practice of string concatenation for sql query building rather than utilizing prepared statements with bound parameters.
The operational impact of this vulnerability is severe as it provides authenticated attackers with extensive data exfiltration capabilities within the Koha library management system. Since the attacker needs only staff authentication and reports module permissions, the attack surface is relatively broad compared to other database vulnerabilities requiring elevated privileges or complex exploitation chains. The exposure of password hashes and session information directly enables account takeover scenarios, while access to api_keys could allow attackers to escalate their privileges further within the system. This vulnerability aligns with attack techniques documented in the mitre att&ck framework under initial access and credential access phases, specifically targeting the use of valid accounts for privilege escalation and data theft.
Mitigation strategies should focus on implementing proper input validation and parameterization practices throughout the application codebase. All dynamic sql construction must utilize prepared statements with bound parameters to prevent user input from being interpreted as sql commands. The specific vulnerable code path in calculate subroutine needs immediate remediation through input sanitization and query restructuring to eliminate direct string interpolation of filter parameters. Additionally, implementing proper access controls and principle of least privilege for database users can limit the damage scope even if other vulnerabilities exist. Regular security code reviews should be conducted to identify similar patterns that may exist elsewhere in the application, particularly focusing on sql query construction practices and input handling mechanisms.