September 2026 - Koha-bugs - lists.koha-community.org

[Bug 42736] SQL Injection in reports/cat_issues_top.pl via Criteria / Filter request parameters (unvalidated string context, no placeholders)
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42736 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42800] Potential XSS in shelf list in the erm module
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42800 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42904] Prevent XSS in patron restriction comments
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42904 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42274] New: opac-tags.pl should return JSON instead of JS script
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42274 Bug ID: 42274 Summary: opac-tags.pl should return JSON instead of JS script Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org koha-tmpl/opac-tmpl/bootstrap/js/tags.js makes AJAX calls to ./opac/opac-tags.pl which returns Javascript scripts rather than JSON. The crazy part is that it's mostly just returning a JSON object anyway. There are some gotchas where it returns a JS object with embedded KOHA.Tags.tag_message() functions, but I'm sure we can fix that. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 42264] New: Ungrouping holds or grouping existing holds requires top-line reserveforothers permission
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42264 Bug ID: 42264 Summary: Ungrouping holds or grouping existing holds requires top-line reserveforothers permission Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com While staff with the place_holds permission (and no other permissions from reserveforothers) *can* create a hold group by selecting multiple bibs in search results and choosing the 'Treat as hold group' option on the 'Place holds' screen, they cannot create a hold group from existing 'standard' holds or ungroup a hold group. Grouping existing holds and ungrouping holds requires the top-line reserveforothers permission, but it should either be part of place_holds or be a separate permission so that staff needn't also have alter_hold_targets and modify_holds_priority in order to use hold groups. To replicate the error with creation: -Use a staff patron account with only the place_holds permission from the reserveforothers group -Create 2 or more standard holds for another patron -In the regular patron's account, select the standard holds and click 'Group holds' -On the modal, click 'Group' -Note the error message: "Authorization failure. Missing required permission(s)." To replicate the problem with ungrouping: -Find/create a patron with a group hold using a staff account with top-line reserveforothers permission -Sign in using a staff patron account with only the place_holds permission from reserveforothers -Go to the regular patron account where the group hold was placed -Click the number in the 'Hold group' column, then select 'Ungroup holds' from the modal -Note that the modal disappears with no error message, but the hold has not been ungrouped -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43435] New: opac-detail.pl crashes with "Can't call method itemtype on an undefined value" — repeated occurrences correlate with Starman worker panics (fold_constants JMPENV_PUSH) and worker process death
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43435 Bug ID: 43435 Summary: opac-detail.pl crashes with "Can't call method itemtype on an undefined value" — repeated occurrences correlate with Starman worker panics (fold_constants JMPENV_PUSH) and worker process death Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: HP OS: Linux Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: rafiqur83(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 204573 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204573&action=e… opac-detail.pl crashes with "Can't call method itemtype on an undefined value" — repeated occurrences correlate with Starman worker panics (fold_constants JMPENV_PUSH) and worker process death We are running Koha 25.11.04.000 in production and are experiencing a recurring, ongoing issue where OPAC requests to opac-detail.pl trigger a Perl runtime error, and — when this error coincides with a Plack/Starman graceful shutdown signal (e.g. from log rotation, worker recycling via max_requests, or a manual/automated restart) — the affected worker child processes crash with a low-level Perl interpreter panic instead of shutting down cleanly. This causes our Starman worker pool to gradually shrink over time (sometimes down to 0-1 active workers out of a configured 6), resulting in severe OPAC slowness/unavailability until Plack is manually or automatically restarted. Error 1 — recurring, very frequent (multiple times per hour under normal traffic) Can't call method "itemtype" on an undefined value at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 749. We have NOT been able to isolate this to one specific biblionumber or item record: item-level_itypes system preference = 1 (item-level, not biblio-level) No items found with NULL/empty itype (checked via SQL) Only 2 biblio records had NULL biblioitems.itemtype (21729, 31981) — expected/normal since item-level_itypes=1 Correlating access logs against error log timestamps did not reliably identify a single problem record; the error occurs across many different requests over time, suggesting it may be triggered by a specific (but not-yet-identified) data condition (e.g. an item with missing/orphaned data referenced transiently, or a race condition in item retrieval) rather than one permanently broken record. We would appreciate guidance on what conditions cause an item object to be undefined at opac-detail.pl line 749, so we can identify the underlying data issue on our end, and suggest the code add a definedness check before calling ->itemtype to avoid the fatal error regardless of data condition. Error 2 — Perl interpreter panic, occurs specifically when a shutdown/restart signal arrives during request handling panic: fold_constants JMPENV_PUSH returned 2. panic: gen_constant_list JMPENV_PUSH returned 2. Child process XXXXX exited with status 29 Sample from our plack-error.log (timestamps redacted for brevity, full log available on request): 2026/09/01-09:48:27 Received QUIT. Running a graceful shutdown Sending children hup signal panic: fold_constants JMPENV_PUSH returned 2. panic: fold_constants JMPENV_PUSH returned 2. panic: fold_constants JMPENV_PUSH returned 2. panic: fold_constants JMPENV_PUSH returned 2. Child process 8344 exited with status 29 Child process 8343 exited with status 29 Child process 8347 exited with status 29 Child process 8345 exited with status 29 2026/09/01-09:48:27 Worker processes cleaned up 2026/09/01-09:48:27 Server closing! This panic appears to occur when Starman sends a QUIT/graceful-shutdown signal to workers while a worker is in the middle of handling a request that would otherwise trigger the "itemtype on undefined value" error above (or similar warning/exception). Instead of a clean shutdown, the child process panics and exits with an abnormal status (4 or 29), rather than completing its current request and exiting normally. Observed effect Because our environment restarts Plack periodically (via our own monitoring script when worker count drops, and previously via routine log rotation / max_requests recycling), the panic gets triggered repeatedly throughout the day, each time killing multiple worker children simultaneously. Over hours, this depletes the worker pool faster than it can be replenished, causing severe performance degradation for library patrons. Steps to Reproduce Run Koha 25.11.04.000 under Plack/Starman with max_requests set (we use 60; also reproduced with 200 and 1000) Allow normal OPAC browsing traffic (including search engine/social media crawlers hitting opac-detail.pl for various biblionumbers) to occur At some point, the "Can't call method itemtype on an undefined value" error will appear in plack-error.log for some biblionumber (we have not found a 100% reliable manual reproduction step — it appears data/record-dependent and we could not pin down the exact triggering record despite investigation) If a Plack restart (graceful QUIT signal) occurs at approximately the same time as one of these errors is being processed by a worker, that worker (and often several others active at that moment) will panic with fold_constants JMPENV_PUSH returned 2 instead of shutting down gracefully Expected behavior opac-detail.pl should not throw a fatal "Can't call method itemtype on an undefined value" error for any valid request — it should handle missing/undefined item data gracefully (e.g., skip display of item-level details, or show a "not available" message) rather than crashing the whole request. A graceful shutdown signal (QUIT) arriving during request/error handling should never cause a Perl-level panic that kills the worker process abnormally. Actual behavior opac-detail.pl fatally errors on line 749 for certain (unidentified) records/requests. When a shutdown signal coincides with this error being raised, the worker process panics and dies abnormally (exit status 4 or 29) instead of shutting down cleanly, contributing to a shrinking worker pool over time. Environment Koha version: 25.11.04.000 OS version (uname -a): Linux localhost 6.12.100+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.100-1 (2026-07-30) x86_64 Perl interpreter: /usr/bin/perl Perl version: 5.040001 MySQL version: 11.8.6-MariaDB-0+deb13u1 from Debian Apache version: Apache/2.4.68 (Debian) PSGI: Plack (deployment) Zebra version: Zebra 2.2.8, Using ICU Message broker: RabbitMQ Plack configuration: plack_workers: 6 plack_max_requests: 60 (also reproduced at 200 and 1000) Additional notes We suspect this may be related to running on a relatively new/bleeding-edge stack (Perl 5.40.1 on Debian 13 "Trixie") — the fold_constants JMPENV_PUSH panic is a historically rare Perl-core-level issue previously seen with older Perl+Plack/Starman combinations; we are not certain if it is specific to Perl 5.40 or triggered by something in Koha's exception-handling path. We are happy to provide additional diagnostic information, full log excerpts, or test on our instance if that would help narrow down the root cause. This is a production library catalog (OPAC) serving real patrons, so we would appreciate any guidance on a temporary code-level workaround (e.g., a defensive if (defined $item) check around line 749) while a permanent fix is developed. Thank you for your time reviewing this report. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 36154] New: Add images to the lists and loan histories
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '26

04 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36154 Bug ID: 36154 Summary: Add images to the lists and loan histories Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.le-gac(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Display images in lists and loan histories in both OPAC and the staff interface, similar to when conducting a search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 43468] New: script tags in additional-contents should be scrubbed/disallowed
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43468 Bug ID: 43468 Summary: script tags in additional-contents should be scrubbed/disallowed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- to recreate: 1. add a news item like: <script> console.log('hello world') </script> 2. go to the main page and see in the console, hello world Is there a reason to allow this? Shouldn't all JS go in via the UserJS system prefs? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 34867] New: Select multiple libraries in Tools (News, HTML customizations and Pages)
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34867 Bug ID: 34867 Summary: Select multiple libraries in Tools (News, HTML customizations and Pages) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In Tools (News, HTML customizations, and Pages) staff can select all libraries or an individual branch. It would be nice if staff could select multiple libraries. Similar to what we do with library limitations in patron categories, authorized values, etc. This would make the creation of News, HTML customizations, and/or Pages easier for large systems, multi-branch, or campuses. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 16207] New: Incorporate circulation and fine rules for library groups
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16207 Bug ID: 16207 Summary: Incorporate circulation and fine rules for library groups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I think we could simplify circulation and fine rules by incorporating library groups into the mix. For example, I have 27 libraries, and 8 of them follow the same set of rules that are different from the defaults. So, what if instead of cloning these special rules to 8 different libraries (and who knows how many other duplicated sets of rules there are), we defined a set of rules for a library group. If the library is part of that group, it goes by those rules. I don't know if we want to use the same library groups that are already defined in the libraries and groups, or if we want to create a unique Circ rule group. Because, there is always the chance that one or more of the libraries in the 8 that are grouped together by affiliation or region could have a slightly different set of rules. However, I think rules by groups would make managing rules far less complicated than managing groups of cloned rules. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15