CVE-2026-55383 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 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 therefore disclose a different company's document when numeric identifiers collide, and an expired token can remain usable on the JSON routes GET /customer/invoices/{email_log:token}, GET /customer/estimates/{email_log:token}, and GET /customer/payments/{email_log:token}. View handlers can also mark a mismatched invoice or estimate as viewed and send a notification. This issue is fixed in version 2.4.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified within InvoiceShelf prior to version 2.4.0 represents a critical failure in access control logic, specifically manifesting as an insecure direct object reference combined with improper validation of security tokens. The application utilizes EmailLog entities to manage the distribution and tracking of invoices, estimates, and payments via unique tokens sent to customers. These tokens are designed to provide secure, temporary access to specific financial documents hosted on public routes. However, the underlying implementation relies heavily on numeric identifiers for these resources without implementing sufficient cross-referencing or type verification mechanisms. This architectural flaw allows an attacker to manipulate input parameters in a way that bypasses intended security boundaries, leading to unauthorized data exposure and potential operational disruption.
At the technical core of this vulnerability is the lack of validation regarding the mailable_type field associated with EmailLog tokens. When a user accesses routes such as GET /customer/invoices/{email_log:token}, GET /customer/estimates/{email_log:token}, or GET /customer/payments/{email_log:token}, the application extracts the numeric identifier from the token and queries the database for that specific ID. Crucially, it fails to verify whether the retrieved record's type matches the expected document category implied by the route being accessed. In systems where identifiers are sequentially generated integers, there is a non-negligible probability of collision or overlap between different entities within the same company or across different companies if shared database structures are used without strict isolation checks. Consequently, an attacker can iterate through numeric IDs to discover valid tokens for documents they do not own. If a token issued for one document type corresponds numerically to another existing record, the application may disclose that unrelated document, effectively bypassing authentication and authorization controls entirely.
Furthermore, the vulnerability is exacerbated by the failure of JSON handlers to enforce expiration checks on EmailLog tokens via the isExpired property. Security best practices dictate that time-sensitive access tokens must be invalidated after a specific duration or upon first use to prevent replay attacks and reduce the window of opportunity for exploitation. In this case, expired tokens remain functional when accessed through the specified API endpoints. This means that even if an attacker obtains a token from old logs, email archives, or other sources where it was previously exposed, they can still retrieve sensitive financial information long after the intended validity period has passed. The combination of missing type verification and absent expiration checks creates a compounded risk profile where both temporal and contextual integrity are compromised.
The operational impact of this vulnerability extends beyond simple data leakage to include potential privacy violations and reputational damage for affected businesses. Since InvoiceShelf handles sensitive financial data including invoice amounts, payment statuses, and customer contact information, unauthorized access constitutes a significant breach of confidentiality. Additionally, the ability to mark mismatched invoices or estimates as viewed introduces an integrity risk. An attacker could artificially inflate view counts on documents they do not own, potentially triggering automated notifications to company staff regarding activity that did not originate from legitimate customers. This can lead to operational confusion, wasted investigative resources, and a degradation of trust in the system's reliability. For small businesses relying on this tool for financial operations, such breaches may also violate regulatory requirements concerning data protection and customer privacy.
This flaw aligns with CWE-284 Improper Access Control, as it involves insufficient verification of authorization before granting access to resources. It is further categorized under CWE-613 Insufficient Session Expiration because the system fails to properly invalidate tokens after their intended lifespan. From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability facilitates Initial Compromise and Collection through techniques associated with Unsecured Credentials or Exploitation for Data Staging. The ability to enumerate resources via numeric IDs also touches upon CWE-200 Information Exposure, as it allows attackers to discover valid resource identifiers that were not intended to be publicly accessible in a predictable manner.
Mitigation strategies must focus on implementing robust validation logic and enforcing strict security controls at the application layer. Developers should ensure that every access request verifies both the existence of the token and its contextual validity by checking that the mailable_type matches the expected type for the requested route. This prevents cross-type data leakage even if numeric collisions occur. Additionally, all JSON handlers must explicitly check the isExpired status before processing any requests involving EmailLog tokens, ensuring that expired credentials are rejected immediately regardless of their current state in the database. Implementing rate limiting on these public endpoints can also help mitigate enumeration attacks by detecting and blocking rapid sequential access attempts to different numeric IDs. Upgrading to version 2.4.0 or later is essential as it addresses these fundamental flaws in token handling and validation logic, restoring the integrity of the access control model for InvoiceShelf users.