CVE-2026-55387 in InvoiceShelf
Summary
by MITRE • 10/15/2026
InvoiceShelf is an open-source web & mobile app that helps track expenses, payments and create professional invoices and estimates. In version 2.3.3 and earlier, InvoiceShelf bulk-delete request validation accepts record identifiers without consistently binding them to the authenticated user's company_id. The affected DeleteCustomersRequest, DeleteEstimatesRequest, DeleteExpensesRequest, DeleteInvoiceRequest, DeleteItemsRequest, DeletePaymentsRequest, and DeleteUserRequest validators check that identifiers exist but do not consistently check tenant ownership. An authenticated user can submit another company's identifier and delete cross-company records. This vulnerability is fixed in 2.4.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in InvoiceShelf versions prior to 2.4.0 represents a critical failure in multi-tenant isolation, specifically within the bulk deletion endpoints for various resource types including customers, estimates, expenses, invoices, items, payments, and users. As an open-source application designed for financial tracking and invoice generation, maintaining strict data segregation between different companies or tenants is paramount to ensuring confidentiality and integrity. The core technical flaw lies in the request validation logic implemented across multiple classes such as DeleteCustomersRequest, DeleteEstimatesRequest, DeleteExpensesRequest, DeleteInvoiceRequest, DeleteItemsRequest, DeletePaymentsRequest, and DeleteUserRequest. While these validators successfully verify that the provided record identifiers exist within the database, they fail to consistently bind or validate those identifiers against the company_id associated with the authenticated user's session. This oversight creates a direct path for unauthorized data manipulation by bypassing standard access control checks.
From an operational perspective, this flaw allows any authenticated user to perform cross-company deletions if they can obtain valid record identifiers belonging to another tenant. In practical terms, an attacker who has compromised or possesses credentials for one account could potentially delete financial records, customer information, or invoice data associated with a completely different organization using the same platform. This not only leads to significant data loss and operational disruption but also constitutes a severe breach of confidentiality. The ability to alter or destroy data belonging to other tenants undermines the fundamental trust model required in Software-as-a-Service environments where multiple independent entities share infrastructure while expecting logical separation of their sensitive business data.
This vulnerability is classified under CWE-602, which describes Client-Side Enforcement of Server-Side Access Control. The root cause is the reliance on client-supplied identifiers without sufficient server-side validation to ensure that these resources belong to the requesting user's tenant context. In terms of offensive security frameworks, this behavior aligns with ATT&CK technique T1485, specifically the Data Destruction sub-technique, as it enables an actor to destroy data in a target environment. Furthermore, because the issue stems from improper authorization checks on API endpoints, it also relates to CWE-269, Improper Privilege Context, where the system fails to enforce appropriate boundaries between different security contexts or tenants.
To mitigate this vulnerability and prevent similar issues in future development cycles, developers must implement strict tenant isolation logic within all bulk operation handlers. This involves ensuring that every database query for deletion explicitly includes a filter condition matching the authenticated user's company_id against the resource being deleted. Additionally, implementing automated testing suites that specifically target cross-tenant access scenarios can help detect such logical flaws early in the development lifecycle. Organizations currently running InvoiceShelf versions 2.3.3 and earlier should immediately upgrade to version 2.4.0 or later where this validation logic has been corrected to enforce proper ownership checks before allowing any destructive actions on records.