CVE-2026-72607 in Koha
Summary
by MITRE • 08/11/2026
A stored SQL injection vulnerability in Koha through 24.11.17, 25.05.12, 25.11.06, and 26.05.01 allows authenticated staff with the tools => items_batchmod permission to read arbitrary database contents by storing a SQL payload in the agefield value of an automatic item modification rule. The agefield value is stored verbatim to the system preference and later interpolated without parameterization into a SQL query in C4::Items::ToggleNewStatus (line 1228) when the scheduled cron job executes. The injection is SELECT-only under standard MariaDB/MySQL DBI single-statement execution; a time-based SLEEP payload is also achievable via the cron trigger. An attacker can read the entire Koha database including patron PII and staff bcrypt password hashes.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/11/2026
This stored SQL injection vulnerability exists within the Koha integrated library system across multiple versions including 24.11.17, 25.05.12, 25.11.06, and 26.05.01. The flaw specifically targets authenticated staff members who possess the tools => items_batchmod permission, creating a significant security risk for library management systems. The vulnerability stems from improper input validation and sanitization within the automatic item modification rule functionality where the agefield value is stored verbatim into system preferences without any parameterization or escaping mechanisms.
The technical implementation of this vulnerability occurs through the C4::Items::ToggleNewStatus function at line 1228 in the codebase, where user-supplied agefield values are interpolated directly into SQL queries without proper parameterization. This creates a classic stored SQL injection scenario where malicious payloads can be executed when scheduled cron jobs run and process these stored values. The attack vector requires an authenticated staff member with specific permissions to craft and store a malicious payload in the agefield field, which then gets executed during routine system operations.
The operational impact of this vulnerability is severe and multifaceted, particularly given that it allows attackers to read arbitrary database contents including sensitive patron personally identifiable information and staff credentials stored as bcrypt password hashes. Under standard MariaDB/MySQL DBI single-statement execution mode, the injection is limited to SELECT operations, but the time-based SLEEP payloads can also be executed through the cron trigger mechanism, enabling more sophisticated attack techniques such as blind SQL injection. This vulnerability essentially provides attackers with complete database access and can lead to identity theft, privacy violations, and unauthorized system access.
The root cause of this vulnerability aligns with CWE-89 which defines improper neutralization of special elements into SQL commands, and represents a classic case of insufficient input validation and sanitization in web applications. From an ATT&CK framework perspective, this vulnerability maps to T1190 - Exploit Public-Facing Application and T1078 - Valid Accounts, as it requires authenticated access but then escalates privileges to database level access. The attack chain involves initial authentication through valid staff credentials followed by crafting of malicious payloads that exploit the stored injection point, ultimately leading to data exfiltration and potential system compromise.
Mitigation strategies should include immediate patching of affected Koha versions to address the parameterization issue in the C4::Items::ToggleNewStatus function. Organizations must implement proper input sanitization and parameterized queries throughout the codebase, particularly in areas where user-supplied data is stored and later executed. Additionally, access controls should be reviewed to ensure that only necessary staff members have the tools => items_batchmod permission, and regular security audits should validate that all database interactions use parameterized queries or proper escaping mechanisms. Network segmentation and monitoring of cron job execution can also help detect anomalous behavior indicative of exploitation attempts.