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

[Bug 43284] New: ILS-DI: patron data/circulation services lack authentication
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43284 Bug ID: 43284 Summary: ILS-DI: patron data/circulation services lack authentication Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: akhdanarif456(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 203573 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203573&action=e… Proof of concept in local deployment of 26.05.02 with ILS-DI enabled and allowlist ip in ILS-DI:AuthorizedIPs The ILS-DI services (opac/ilsdi.pl) expose patron data and circulation operations (renew loan, place hold) with no authentication and no per-user authorization. The only access control is the ILS-DI:AuthorizedIPs IP allowlist. Once a request passes that IP check, anyone can read any patron's personal data and perform actions on behalf of any patron, using only predictable numeric IDs. Exploitable when: ILS-DI is enabled and the client IP is in ILS-DI:AuthorizedIPs . Where those hold, authentication is entirely absent. Reproduce: 1. Setup: enable ILS-DI = 1, add attacker IP to ILS-DI:AuthorizedIPs. 2. Read + enumerate patron data (no auth): GET /cgi-bin/koha/ilsdi.pl?service=GetPatronInfo&patron_id=2&show_contact=1 3. State-changing (no auth): GET /cgi-bin/koha/ilsdi.pl?service=RenewLoan&patron_id=2&item_id=1 & GET /cgi-bin/koha/ilsdi.pl?service=HoldTitle&patron_id=2&bib_id=1&request_location=127.0.0.1 Actual Results: 1. GetPatronInfo returns full PII (address, phone, cardnumber, city) for any patron; enumeration dumps the whole patron database. 2. RenewLoan extends the loan: date_due changed 2026-08-26 → 2026-08-31 ( <success>1</success>). 3. HoldTitle creates a hold on behalf of the victim: reserves count 0 → 1. All verified on a live local deployment of 26.05.02. Expected Results: Patron-facing services should require the caller to authenticate as that patron (via AuthenticatePatron, which already exists) or as staff with permission. the IP allowlist should not be the only control. Security Hardening Gap: 1. IP allowlist is single-factor, and IPs can be spoofed/shared (VPN, NAT, shared server). If a discovery layer is used by many people or its IP is shareable, anyone on that IP can access all patron data. 2. No per-user audit trail. All requests are anonymous, hard to forensically trace. 3. CSRF exemption for /ilsdi.pl remains a problem for state-changing services if the IP gate is bypassed. Root cause: opac/ilsdi.pl never calls checkauth(); it sets an anonymous userenv and relies solely on the IP allowlist. C4/ILSDI/Services.pm looks up objects purely by numeric ID with no ownership check (GetPatronInfo, RenewLoan, HoldTitle, HoldItem, GetPatronStatus, GetServices, LookupPatron). Contrast: CancelHold does contain an ownership check — so the missing checks elsewhere are an inconsistency/oversight, not uniform design. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 --- Comment #3 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- Created attachment 203572 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203572&action=e… Bug 43283: Change event handler to work on all dT pages To test: 1. Have 25+ patron lists w/ at least 1 borrower 2. On the list of patron lists page ( lists.tt ) use the Actions button to choose 'Print patron cards' 3. On the first dT page it should open in modal ( good ) 4. On any subsquent pages it will not open in a modal and you cannot export the file ( bad ) 5. APPLY PATCH 6. Try again. The 'Print patron cards' should open in a modal on every page -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs(a)lists.koha-commun |lucas(a)bywatersolutions.com |ity.org | Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 --- Comment #2 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- Attaching the event handler directly to the element only works when you don't paginate with dataTables: $(".print_cards").on("click", function (e) { -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43283] Can't print patron cards from list unless list is on the first page of results
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43283 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas(a)bywatersolutions.com --- Comment #1 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- It took me a while to recreate this, I needed to have 25+ lists to do so. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43278] Add Koha::CsvProfile->parsed_fields and profile-aware CSV export
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43278 Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41621 CC| |tomascohen(a)gmail.com Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41621 [Bug 41621] Use Koha::CSV everywhere [UMBRELLA] -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41621] New: Use Koha::CSV everywhere
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41621 Bug ID: 41621 Summary: Use Koha::CSV everywhere Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 30777] New: stockrotationitems table could store additional information
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30777 Bug ID: 30777 Summary: stockrotationitems table could store additional information 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: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be very helpful if stockrotationitems had more information, especially when it was added to the rota. It might also be helpful to have when the last time it was moved by the stock rotation cron. If we could also have the remaining duration that would be great, but I also think would be trickier. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 40393] New: Stock Rotation: Items returned to unexpected branch after ownership change do not trigger correct transfer
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '26

12 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40393 Bug ID: 40393 Summary: Stock Rotation: Items returned to unexpected branch after ownership change do not trigger correct transfer Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.adamyk(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the stock rotation cronjob updates an item's owning library and creates a pending transfer, Koha doesn't properly handle cases where the item is checked out or waiting on a holdshelf when the cron runs to change the branch, and then the item is checked in at a different branch than the one listed in branchtransfers.frombranch. When checked in at an unexpected branch, Koha doesn't prompt a transfer at all, which leaves an open transfer request that staff are unaware of. If the item is checked in a second time, Koha will properly prompt the transfer. Steps to reproduce: 1. Set up stock rotation and add a test item to the rotation schedule. 2. Check the item out before the cronjob runs to change the item's branch. 3. Run the stock rotation cronjob to move all items to the next branch. 4. Check in the item at a different branch (neither the old or new owning branch). 5. Note that Koha does not prompt a transfer on the item. 6. The item should have a pending transfer that was not triggered. 7. Check the item in again to trigger the transfer. Note: Is it possible this issue relates or overlaps with the following bugs? * Bug 40331 * Bug 36658 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1