CVE-2026-55382 in InvoiceShelf
Summary
by MITRE • 10/14/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, InvoiceShelf NotesController::show, NotesController::update, and NotesController::destroy authorize only the generic view notes or manage notes ability and do not pass the route-bound Note to NotePolicy::viewNotes or NotePolicy::manageNotes, so neither method checks the target note's company_id. Because the Note model has no global company scope, an authenticated staff user with ordinary note abilities can select another company's sequential note identifier and read, modify, or delete its reusable invoice, estimate, and payment note templates. This issue is fixed in version 2.4.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within InvoiceShelf prior to version 2.4.0 represents a critical failure in object-level authorization logic, specifically affecting the NotesController methods for showing, updating, and destroying notes. In multi-tenant SaaS architectures like InvoiceShelf, where multiple distinct companies share the same application instance, it is imperative that access control mechanisms strictly enforce data isolation between tenants. The core technical flaw lies in how the controller interacts with its associated policy classes. When a user requests to view, modify, or delete a note resource, the controller passes only generic permission flags such as view notes or manage notes to the NotePolicy methods. Crucially, it fails to pass the specific route-bound Note model instance that contains the target record's metadata, including the company_id foreign key.
Because the policy methods do not receive the actual object being accessed, they are unable to perform tenant-scoped validation checks. The underlying database schema for the Note model lacks a global scope that would automatically filter queries by the authenticated user's organization. Consequently, the authorization logic effectively becomes blind to which specific company owns the targeted resource. This architectural oversight allows an attacker who possesses valid authentication credentials and standard note management permissions to bypass tenant isolation boundaries entirely. By manipulating the identifier in the request URL, typically through a sequential integer value representing the primary key of the database record, the user can target resources belonging to other organizations within the same system instance.
The operational impact of this vulnerability is severe due to its implications for data confidentiality and integrity across multiple tenants. An authenticated staff member with ordinary note abilities can read sensitive information from another company's reusable invoice templates, estimate drafts, or payment notes. This exposure potentially reveals proprietary pricing structures, client contact details, contractual terms, and financial strategies that are intended to be strictly confidential within a specific business entity. Furthermore, the ability to update or destroy these records allows for malicious modification of critical business documents or complete deletion of important historical data. Such actions can lead to significant operational disruption, legal liabilities arising from unauthorized access to protected information, and erosion of trust in the platform's security posture among enterprise customers who rely on strict multi-tenancy guarantees.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure to enforce proper restrictions on untrusted inputs regarding object identifiers. It also maps directly to MITRE ATT&CK technique T1530 Data from Cloud Storage Object Misconfiguration or more broadly to data exfiltration techniques where an attacker accesses resources outside their authorized scope. The root cause is a classic Insecure Direct Object Reference (IDOR) pattern, exacerbated by the absence of automatic scoping mechanisms in the ORM layer that would otherwise enforce tenant boundaries transparently during database queries.
To mitigate this vulnerability and prevent similar issues in future development cycles, it is essential to implement robust object-level authorization checks within the policy classes themselves. The NotePolicy methods must receive the specific resource instance as a parameter and explicitly verify that the company_id of the requested note matches the company_id associated with the authenticated user's session or tenant context. If these identifiers do not match, access should be immediately denied regardless of the generic permissions granted to the role. Additionally, developers should consider implementing global database scopes for multi-tenant models like Note, ensuring that all read and write operations are automatically filtered by the current tenant ID at the query level. This defense-in-depth approach ensures that even if application-level logic fails, the data layer itself prevents cross-tenant access. Upgrading to version 2.4.0 or later resolves this issue as it corrects the controller-to-policy interaction to include proper context passing and validation.