CVE-2026-55385

In InvoiceShelf version 2.3.3 and earlier, bulk-delete request validation accepts record identifiers without consistently binding them to the authenticated user's company_id. An authenticated user can submit another company's identifier and delete cross-company records.

Prior to version 2.4.0, InvoiceShelf passes the authenticated user's orderByField query parameter into Laravel orderBy calls in Invoice::scopeApplyFilters without restricting the value to column identifiers. A crafted SQL expression can enter the ORDER BY clause, enabling boolean-based blind extraction of database information.

In InvoiceShelf prior to version 2.4.0, invoice, estimate, and recurring-invoice creation paths accept client-supplied total, sub_total, tax, discount_val, and due_amount values without verifying that they match the submitted line items. An authenticated user can persist manipulated financial totals through InvoicesRequest::getInvoicePayload and the corresponding EstimatesRequest and RecurringInvoiceRequest handlers.

Prior to version 2.4.0, InvoiceShelf public customer invoice, estimate, and payment routes use an EmailLog token's numeric mailable_id without verifying mailable_type, and the JSON handlers do not enforce EmailLog::isExpired. A token issued for one document type can disclose a different company's document when numeric identifiers collide, and an expired token can remain usable on the JSON routes.

Prior to version 2.4.0, InvoiceShelf NotesController::show, update, and destroy authorize only the generic view notes or manage notes ability and do not pass the route-bound Note to NotePolicy, so neither method checks the target note's company_id. An authenticated staff user can read, modify, or delete another company's note templates.

Prior to version 2.4.0, POST /api/v1/estimates/{estimate}/convert-to-invoice authorizes only the caller's create-invoice ability and does not authorize access to the route-bound Estimate. An authenticated user can copy another company's line items, prices, totals, taxes, notes, currency, and customer data into an invoice in their own company.

InvoiceShelf prior to version 2.4.1 in multi-company installations allows an Owner of one company to read and overwrite any user account in any other company. The vulnerability stems from missing verification that the target user belongs to the requester's company, enabling account takeover.

InvoiceShelf prior to version 2.2.0 has an SSRF vulnerability in the PDF generation module. User-supplied HTML in the Notes field is passed unsanitized to the Dompdf library, which fetches remote resources, exploitable via PDF preview and email delivery endpoints.

InvoiceShelf before version 2.2.0 has an SSRF vulnerability in the PDF receipt generation module. User-supplied HTML in the Notes field is passed unsanitized to Dompdf, which fetches remote resources, enabling SSRF attacks.

InvoiceShelf before version 2.2.0 has an SSRF vulnerability in the PDF estimate generation module. User-supplied HTML in the Notes field is passed unsanitized to Dompdf, which fetches remote resources, enabling SSRF attacks.