CVE-2026-72607

Executive Summary

CVE-2026-72607 is a stored SQL injection vulnerability in the Koha open-source Integrated Library System (ILS). Versions through 24.11.17, 25.05.12, 25.11.06, and 26.05.01 are affected. An authenticated staff user holding the tools => items_batchmod permission can inject a SQL payload into the agefield value of an automatic item modification rule. This payload is stored unparameterized and later interpolated into a SQL query executed by the C4::Items::ToggleNewStatus routine (line 1228) when the scheduled cron job fires. Successful exploitation permits full read access to the underlying Koha database, including patron personally identifiable information (PII) and bcrypt password hashes for staff accounts. The CVSS score is 7.1 (High) with a vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L. No patch is currently available.

Technical Analysis

Vulnerability Class: Stored SQL Injection (CWE-89).

Mechanism: The flaw resides in how Koha handles the agefield parameter within automatic item modification rules. These rules are administrative constructs that define how item records should be automatically transformed—typically to set or clear status flags (e.g., new, damaged, lost) based on aging criteria. The agefield value dictates which date field in the item record is consulted to determine the item's age.

The vulnerable operation begins when an authenticated staff member with the tools => items_batchmod permission creates or edits an automatic item modification rule and includes a malicious SQL payload in the agefield input field. Crucially, the application stores this value verbatim without any validation, sanitization, or encoding. This constitutes the stored part of the injection—the malicious content is persisted to the system preferences table in the database.

The triggered part of the injection occurs later, asynchronously, when Koha's scheduled cron job iterates over item records to apply automatic modifications. For each item that matches the rule's criteria, the application constructs a dynamic SQL UPDATE statement. The agefield value is pulled from the database and interpolated directly into this SQL query string without parameterization. This query assembly takes place in the C4::Items::ToggleNewStatus Perl routine, specifically at line 1228. The resulting query is then submitted to the SQL engine (MariaDB/MySQL under standard DBI single-statement execution).

Because the agefield is an attacker-controlled string that is concatenated into the SQL statement, a crafted payload can break out of the intended string or identifier context and append additional SQL clauses. The description notes that under standard single-statement DBI semantics, the injection is restricted to SELECT operations. However, a time-based SLEEP() payload can be embedded to confirm the vulnerability and exfiltrate data in a blind manner via response-time differentials.

Attack Surface & Preconditions:

• Authentication: Required (authenticated staff with specific permission).
• Authorization: The attacker must hold the tools => items_batchmod permission. This is a legitimate but moderately privileged role, typically assigned to staff responsible for batch item maintenance. The permission is not usually granted to guests or low-privilege patrons.
• Network Exposure: The core vulnerability is in the application logic (stored in DB → used in cron). No direct network request is needed to trigger the exploit; the cron job is the trigger mechanism.
• Database: MariaDB/MySQL. The restriction to SELECT-only payloads is tied to DBI's single-statement execution mode; multi-statement mode is not enabled.

Exploitation Scenarios

Note on PoC: No public PoC, Nuclei template, or exploit code exists for this CVE. The attack chain below is inferred from the vulnerability class, the NVD description, and the explicit mention of the vulnerable code path in C4::Items::ToggleNewStatus.

Step 1 — Reconnaissance & Target Identification: An attacker who is an authenticated staff user of a Koha instance identifies targets by testing the automatic item modification rule functionality. The attacker first confirms they have the tools => items_batchmod permission. They may also probe whether the target database is MariaDB/MySQL (versus PostgreSQL) by examining system preference values or error behavior, though this is not strictly required for exploitation.

Step 2 — Flaw Trigger — SQL Payload Injection (Stored Component): The attacker navigates to the administrative interface for automatic item modification rules. They create a new rule (or edit an existing one) and, in the field that is stored as the agefield value, submit a carefully crafted SQL payload. Because the application stores the input verbatim, the payload is committed to the database as part of the rule's configuration. A representative payload—at the vulnerability-class level—would resemble something like: a string that terminates the intended SQL expression and appends a UNION-based SELECT subquery designed to extract data from a known table. (This is a class-level example; the actual expression syntax is not provided in the NVD description.)

Step 3 — Payload Execution (Triggered Component): The attacker does not need to initiate a separate request to execute the injected SQL. They wait for the scheduled cron job that processes automatic item modification rules. When the cron job runs, C4::Items::ToggleNewStatus is invoked. At line 1228, the stored, attacker-controlled agefield value is concatenated into a SQL query string. The query is sent to the database using DBI in standard single-statement mode. The injected SELECT payload is therefore executed in the context of the Koha application's database connection.

Because direct data return is not possible through the cron job's output path, the attacker would likely use a time-based blind technique (e.g., SLEEP() with a conditional clause) to infer data one bit or character at a time by measuring query execution time. Alternatively, if the cron job's output or error logging is accessible to the attacker, results may be visible in those logs.

Step 4 — Post-Exploitation Impact: With the ability to execute arbitrary SELECT queries, the attacker can systematically enumerate the Koha database. Primary targets include:

• The patrons table, which contains names, addresses, contact details, birthdates, and other PII.
• The borrowers/staff table, which contains bcrypt password hashes for staff accounts.
• System configuration tables, potentially revealing API keys, Z39.50/SRU credentials, and SMTP credentials used for Koha's outgoing email.

Exfiltrated data may be used for identity theft, credential stuffing against the Koha instance or other internal systems if passwords are reused, or further lateral movement within the library's network. The confidentiality impact is high (CVSS C:H); availability impact is low (A:L) because the payload is SELECT-only and cannot directly modify or delete data.

Impact Assessment

Business Impact: Koha is a widely deployed open-source ILS used by public, academic, school, and special libraries globally. A compromise of the underlying database exposes patron PII, which is subject to privacy regulations (e.g., FERPA for K-12 in the US, GDPR in Europe). The presence of bcrypt-stored staff password hashes elevates the risk of credential compromise and lateral movement into the library's broader IT environment.

Affected Systems: All Koha installations running versions up to and including 24.11.17, 25.05.12, 25.11.06, and 26.05.01, where the tools => items_batchmod permission has been granted to any staff account, are at risk. Given that batch modification is a standard operational task for cataloging staff, the vulnerable permission is commonly granted in production environments.

Blast Radius & CVSS Subscores:

• Score: 7.1 (High).
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L.
  • Attack Vector (AV:N): Remotely exploitable; the attacker interacts via the web interface.
  • Attack Complexity (AC:L): No special conditions beyond the required permission.
  • Privileges Required (PR:L): Authenticated staff with tools => items_batchmod.
  • User Interaction (UI:N): None required; the cron job triggers the payload.
  • Scope (S:U): The vulnerable component (the database query) is in the same security boundary as the attacker.
  • Confidentiality (C:H): The entire database can be read.
  • Integrity (I:N): SELECT-only; no data modification.
  • Availability (A:L): Low potential for denial of service via SLEEP() payloads saturating the DB connection.

EPSS Score: 0.00266, placing it in the 18.5th percentile of exploited CVEs—indicating a currently low likelihood of active exploitation in the wild, but this may rise once a patch lag or PoC dissemination occurs.

Detection Guidance

Detection of this vulnerability is challenging because the injection is stored and triggered by a server-side cron job rather than a direct HTTP request. Detection must therefore focus on (1) the input that creates the malicious rule and (2) anomalous SQL queries executed by the cron job.

Sigma Rule

Sigma rules are commonly used to detect suspicious process execution or network events. For this server-side, stored-SQLi scenario, the most relevant log source is the Koha application log where SQL queries might be logged. The rule below targets attempts to set the agefield system preference with SQL-like payloads via the staff client.

title: Koha Stored SQL Injection - Suspicious agefield Preference Value
id: 7f0a3c2e-9b1d-4a5c-8d2f-6e1a9b0c4d3a
status: experimental
description: Detects potentially malicious 'agefield' values being set within Koha automatic item modification rules, indicating attempted exploitation of CVE-2026-72607.
author: Valters IT Security Research
date: 2026/06/20
logsource:
    category: application
    product: koha
    definition: 'Requires access to Koha intranet operation logs capturing staff client actions.'
detection:
    selection_agefield:
        EventID:  # Example: Koha action logs
            - 'MODIFY_SYSTEM_PREFERENCE'
            - 'MODIFY_ITEM_RULE'
        Details:  # Raw audit log entry
            '*agefield*'
    selection_sqli_patterns:
        Details|contains:
            - 'union select'
            - 'sleep('
            - 'benchmark('
            - '/*'
            - ';--'
            - "';"
    condition: selection_agefield AND selection_sqli_patterns
level: high
falsepositives:
    - Legitimate system administration using '-1' or numeric values that may not match patterns.
    - Logging of the word 'agefield' in unrelated configuration changes.

YARA Rule

YARA is typically used for file scanning, but it can be applied to logs. This rule targets log or source code files that contain the vulnerable interpolation pattern and evidence of a SQL injection payload in the agefield context.

rule Koha_Agefield_SQLi_CVE_2026_72607
{
    meta:
        author = "Valters IT Security"
        description = "Detects log evidence or source artifacts of the stored SQL injection in Koha agefield (CVE-2026-72607)."
        cve = "CVE-2026-72607"
        date = "2026-06-20"
    strings:
        $s1 = "agefield" nocase
        $s2 = "ToggleNewStatus" nocase
        $s3 = "union" nocase
        $s4 = "select " nocase
        $s5 = "sleep(" nocase
        $s6 = "/**/" nocase
        $s7 = "syspref" nocase
    condition:
        ($s1 and ($s2 or $s7)) and (($s3 and $s4) or $s5 or $s6)
}

Suricata IDS Rule

While the exploit trigger is internal (cron), the storage step occurs via an HTTP request to the Koha intranet interface. This Suricata rule inspects HTTP traffic for attempts to submit SQL payloads within form data destined for Koha's rule-editing scripts. (Note: The exact URI is not public; the rule uses HTTP body inspection.)

alert http any any -> any any (msg:"Koha Stored SQL Injection Attempt - agefield Parameter (CVE-2026-72607)"; flow:established,to_server; http.protocol; content:"POST"; http_method; content:"agefield"; http_client_body; pcre:"/agefield[\"']?\s*[:=]\s*[\"'][^\"']*(union\+select|sleep\s*\(|benchmark\s*\()/i"; classtype:web-application-attack; reference:cve,2026-72607; sid:2026072601; rev:1;)

Elastic Detection

EQL rule for Elastic SIEM. This detects the event of a suspicious modification to a Koha system preference or rule that may indicate injection of a stored payload.

sequence by host.name
  [ any where process.name == "mysqld" or true ] // Step 1: Detect the initial INSERT/UPDATE storing the malicious preference
  with maxspan=1m
  [ any where true ] // Placeholder for the cron job executing the injected query

The above is not precise. A better EQL for the storage step, looking at audit logs:

sequence by user.name
  [ any where message : "*items_batchmod*" and message : "*agefield*" and message : "*union select*" or message : "*sleep(*" or message : "*benchmark(*" ]

Given the lack of specific ECS fields, the following is a more realistic generic EQL:

event.category : "authentication" or event.category : "web"
// Intranet action log named 'MODIFY_SYSTEM_PREFERENCE' with malicious payload
where message : ("*agefield*" and ("*union select*" or "*sleep(*" or "/*"))

Splunk SPL Query

Splunk search for log events where an authenticated staff user modifies a Koha rule and the associated detail contains SQL injection primitives.

index=koha sourcetype="koha:actionlogs:staff"
(Details="*agefield*") 
AND (Details="*union select*" OR Details="*sleep(*" OR Details="*benchmark(*" OR Details="*/*")
| stats count by user, src_ip, Details, _time
| sort _time desc

Wazuh OSSEC Rule

Wazuh rule to alert on malicious agefield modifications in Koha logs.

<group name="koha,">
  <rule id="100726" level="12">
    <decoded>
    </decoded>
    <field name="kauth">MODIFY_SYSTEM_PREFERENCE</field>
    <match>agefield</match>
    <regex>union select|sleep\s*\(|benchmark\s*\(|/\*</regex>
    <description>Koha stored SQL injection attempt detected in agefield (CVE-2026-72607).</description>
    <group>attack,reconnaissance,sql_injection,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Status: CVE-2026-72607 is currently UNPATCHED. Patch confidence is 0/4, and no vendor fix or workaround is documented in the intelligence data. The affected version branches (24.11.x, 25.05.x, 25.11.x, 26.05.x) all contain the vulnerability.

Immediate Mitigations (No Patch Available):

1. Restrict tools => items_batchmod permission. Audit all staff accounts and remove this permission where it is not strictly functionally necessary. At minimum, review the list of users with this permission on a regular basis.
2. Disable the automatic item modification cron job if it is not essential for day-to-day operations. This prevents the vulnerable code path in C4::Items::ToggleNewStatus from executing. If the job must run, consider temporarily removing all automatic item modification rules that use a custom agefield value.
3. If possible, enforce database-level read restrictions. Since the injection is SELECT-only, consider whether a dedicated database user with limited permissions (e.g., no access to borrowers, auth tables) can be used for the cron job's connection. This is a mitigation, not a fix, as the attacker can still read the bulk of the operational catalog data that the cron user has access to.
4. Monitor for anomalous SQL queries. Deploy a database activity monitor or enable MySQL/MariaDB general query log temporarily to identify abnormal SELECT statements containing system tables or large UNION clauses executing during cron windows.

Patch/Upgrade Steps:

• As of the writing of this report, no fixed version has been released. Subscribe to the Koha security mailing list and monitor the Koha community release channels for a patched version addressing CVE-2026-72607 in the 24.11.x, 25.05.x, 25.11.x, and 26.05.x branches.
• Prepare a rollback and upgrade plan to apply the patched version as soon as it is available. Koha releases follow a predictable schedule; anticipated patches will likely be issued for each maintained branch.

Long-Term Hardening:

• Enforce the principle of least privilege. Re-validate all staff permissions quarterly. The items_batchmod permission grants low-level catalog modification that may not be required by all catalogers.
• Secure the Koha intranet interface behind the network firewall or a VPN, especially in environments where staff workstations may be compromised.
• Implement database access controls—do not run the Koha application with superuser-level database credentials.
• Review and attempt to fix the root cause in code: the vulnerability exists because input in agefield is used raw in SQL. Even after the vendor patch, perform a code review of C4::Items::ToggleNewStatus to ensure parameterized queries are used (e.g., ? placeholders in DBI) rather than string interpolation.

References

1. NVD Entry — CVE-2026-72607: https://nvd.nist.gov/vuln/detail/CVE-2026-72607 (Authoritative source for the description, CVSS, and EPSS data.)
2. MITRE CVE List: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-72607
3. Koha Community Website & Security Advisories: https://koha-community.org/security/ (Monitor here for the official patch release and vendor advisory.)
4. CWE-89 — SQL Injection: https://cwe.mitre.org/data/definitions/89.html
5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-72607 is NOT on the KEV list as of the report date; check for updates.)

Threat Actor Context: No known threat actor campaigns or exploit-in-the-wild evidence exist for this CVE. The EPSS score of 0.00266 and the lack of CISA KEV placement indicate that exploitation is not currently widespread. However, stored SQL injection in a widely deployed open-source system is a high-value target for automated scanning campaigns; SOC teams should treat this as a latent risk and maintain detections regardless of current prevalence.