CVE-2026-55381 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. Prior to version 2.4.0, POST /api/v1/estimates/{estimate}/convert-to-invoice in ConvertEstimateController authorizes only the caller's create-invoice ability and does not authorize access to the route-bound Estimate. Because route-model binding can resolve an estimate from any company, an authenticated user with create-invoice ability can copy another company's line items, prices, totals, taxes, notes, currency, and customer data into an invoice in the attacker's company. The victim company's configured conversion action reaches checkForEstimateConvertAction and can also change or delete the original estimate. This issue is fixed in version 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 prior to version 2.4.0 represents a critical failure in object-level access control, specifically manifesting as an Insecure Direct Object Reference (IDOR). The application utilizes route-model binding within its Laravel-based backend architecture to resolve the Estimate resource associated with the URL path parameter for the endpoint POST /api/v1/estimates/{estimate}/convert-to-invoice. While this mechanism efficiently maps a database record to a controller method, it introduces a significant security flaw because the authorization logic only verifies whether the authenticated user possesses the general permission to create invoices within their own company context. It fails to verify that the specific Estimate object being accessed belongs to the same organization as the requesting user or is explicitly shared with them. This architectural oversight allows an attacker who has valid credentials and basic invoice creation privileges to manipulate resources belonging to other tenants in a multi-tenant environment, leading to severe data integrity and confidentiality breaches.
From a technical perspective, the exploitation of this vulnerability relies on the predictable nature of database identifiers often used as route parameters. An authenticated user can simply alter the estimate identifier in the API request payload or URL path to point towards an Estimate record owned by a different company within the same InvoiceShelf instance. Upon receiving this manipulated request, the application resolves the external Estimate object and proceeds with the conversion logic without performing any ownership validation checks against the current session's tenant context. This allows the attacker to extract sensitive financial data from the victim organization, including line items, pricing structures, tax calculations, currency settings, internal notes, and customer personal information. The extracted data is then injected into a new invoice within the attacker’s own company account, effectively stealing proprietary business intelligence and client lists without triggering any access control exceptions or error messages that would typically indicate unauthorized activity.
The operational impact of this vulnerability extends beyond mere data exfiltration due to additional side effects triggered by the conversion action. The victim organization's configured conversion actions are executed on the original Estimate record, which can result in unintended state changes such as modification or deletion of the source document. This means that an attacker does not only steal information but also has the capability to disrupt business operations for other tenants by corrupting or removing critical financial documents. In a multi-tenant SaaS environment where data isolation is paramount, this lack of proper tenant scoping constitutes a severe breach of trust and compliance requirements related to data privacy and integrity. The ability to alter or delete records further escalates the severity from simple information disclosure to potential denial of service and data tampering, affecting the reliability and availability of services for legitimate users.
This vulnerability aligns with CWE-639, which describes Authorization Bypass Through User-Controlled Key, as well as CWE-284, Improper Access Control, since the application fails to enforce proper restrictions on authenticated users regarding access to specific objects. In terms of offensive security frameworks, this behavior is characteristic of ATT&CK technique T1530, Data from Cloud Storage Object Misconfiguration or improper access controls, where an adversary accesses data stored in cloud-based object storage or databases without authorization. To mitigate such risks, developers must implement strict ownership verification at the point of resource resolution rather than relying solely on general role-based permissions. This involves ensuring that every database query for a specific record includes filters for both the primary key and the associated tenant ID to guarantee that the requested resource belongs to the current user's organization. Additionally, implementing comprehensive logging and monitoring for unusual patterns in API requests can help detect attempted exploitation of such flaws before they result in significant data loss or operational disruption.