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

[Bug 42749] SQL injection in acqui/parcels.pl via the orderby parameter (ORDER BY direction) reaching C4::Acquisition::GetInvoices
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

1 0

[Bug 42847] SIP authentication ignored after initial successful connection
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

1 0

[Bug 42866] SQL Injection in Koha/AdditionalContents.pm search_for_display via the patron lang value (stored / second-order, executed on issue-slip print, unvalidated string context, no placeholder)
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

1 0

[Bug 43019] OPAC pages limited to library are readable by unauthenticated users
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

1 0

[Bug 30233] [ZDI-CAN-29165] Remote code execution in user-supplied regex
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

1 0

[Bug 32142] New: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already"
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32142 Bug ID: 32142 Summary: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Relates to Bug 31963. There is an option for the HoldFeeMode system preference "only if all items are checked out and the record has at least one hold already", except it behaved more like "if all items are checked out OR the record has at least one hold already". Bug 31963 fixed this so that the behaviour better matches the description i.e. it says 'and' so that implies BOTH conditions must be met. However we now need an option so that the behaviour from before isn't lost, behaviour like "if all items are checked out or the record has at least one hold already" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 43243] New: Remove pdfmake from DataTables
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43243 Bug ID: 43243 Summary: Remove pdfmake from DataTables Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- For a long time, the bundled datatables library has included "pdfmake" which is required for the "PDF HTML5 export button". But... we don't actually use the "PDF HTML5 export button" in Koha. I also got some hits on ClamAV for : /usr/share/koha/intranet/htdocs/intranet-tmpl/lib/datatables/datatables.min.js: Html.Phishing.SVGDynamicFunction-10060409-0 FOUND /usr/share/koha/intranet/htdocs/intranet-tmpl/lib/datatables/datatables.js: Html.Phishing.SVGDynamicFunction-10060409-0 FOUND A brief look for SVG shows the "pdfmake" library and if you clone that repo and checkout 0.2.7 which is the version we're using... and then run clamav against that you'll get the same hit. However, it looks like it's a false positive. I prove this in my report to pdfmake: https://github.com/bpampuch/pdfmake/issues/2942 So... not a real security problem but it will probably start popping up on people scanning Koha. It does look like the signature doesn't match against the "pdfmake" master branch, so we could look at upgrading the DataTables and its pdfmake library, or we could remove it (although we'll probably need to upgrade our DataTables due to how the DataTables bundler works) -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 30295] New: Send a notification when a recall is manually cancelled
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30295 Bug ID: 30295 Summary: Send a notification when a recall is manually cancelled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The process would be: 1. Recall is cancelled by library staff or the requester. 2. Notification of the recall cancellation is sent via email and SMS to the recall requester. So it would be exactly the same as the HOLD_MANUAL_CANCEL notice that we currently have for reserves, only relevant to recalls. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 42669] New: es_indexer_daemon.pl silently marks jobs finished on indexing failure and doesn't recover from NoNodes
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42669 Bug ID: 42669 Summary: es_indexer_daemon.pl silently marks jobs finished on indexing failure and doesn't recover from NoNodes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 39769 es_indexer_daemon.pl has two issues that cause silent data loss: 1. When update_index() throws an exception (e.g. NoNodes, BadResponse), the exception is caught and logged, but the job is still marked status='finished'. This means records are never re-indexed and silently disappear from search results. 2. The Search::Elasticsearch client (cxn_pool=Static) marks nodes as 'dead' after a connection failure and applies exponential backoff up to 60 minutes. Since the indexer objects are created once at daemon startup, a brief ES restart (e.g. Docker upgrade) leaves the daemon permanently stuck in NoNodes state until manually restarted. Fix: - On NoNodes: abort the batch, recreate the indexer object (resetting the connection pool), and reset jobs to status='new' for automatic retry. - On other indexing errors: mark jobs as 'failed' instead of 'finished'. Test plan: 1. Start es_indexer_daemon.pl 2. Stop Elasticsearch 3. Add/modify a biblio record (triggers indexing job) 4. Verify the job stays in status='new' (not 'finished') 5. Restart Elasticsearch 6. Verify the job is picked up and indexed successfully Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39769 [Bug 39769] es_indexer_daemon.pl uses stale L1 cache -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 42919] New: Suggestion duplicate warning erases suggestion info
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42919 Bug ID: 42919 Summary: Suggestion duplicate warning erases suggestion info Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To recreate: 1. Make a suggestion that will trigger a duplicate warning, in KTD I like "Clothes, clothes, clothes, music, music, music, boys, boys, boys". 2. Fill out some other details, like notes and public notes. 2. The warning says "Click on "Confirm your suggestion" to ignore this message." 3. Notice none of the details are still there. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29