CVE-2026-55384 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, InvoiceShelf 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, causing stored document totals to disagree with their item prices and quantities. 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/15/2026
The vulnerability identified within InvoiceShelf prior to version 2.4.0 represents a critical failure in server-side input validation regarding financial data integrity. As an open-source application designed for tracking expenses, payments, and generating professional invoices and estimates, the system relies heavily on the accuracy of numerical values submitted by users during document creation. The core technical flaw lies in the handling of invoice, estimate, and recurring-invoice creation endpoints, where the backend accepts client-supplied values for total, sub_total, tax, discount_val, and due_amount without performing any verification against the actual line items provided. This architectural oversight allows an authenticated user to bypass logical consistency checks that should ensure mathematical alignment between individual item prices, quantities, and the final calculated totals of the document.
From a technical perspective, this issue stems from improper validation logic within the request handling classes, specifically InvoicesRequest::getInvoicePayload as well as the corresponding EstimatesRequest and RecurringInvoiceRequest handlers. These components are responsible for processing user input before persisting it to the database. Instead of recalculating totals based on the submitted line items or validating that the provided sums match a deterministic calculation derived from those items, the application blindly trusts the values sent by the client. This lack of server-side reconciliation means that an attacker can manipulate these fields to reflect arbitrary financial figures, effectively decoupling the summary data from the detailed transactional data within the same record.
The operational impact of this vulnerability is significant for any organization using InvoiceShelf as a primary tool for billing and expense management. By persisting manipulated financial totals, an authenticated user can create invoices or estimates where the displayed total does not match the sum of its components. This discrepancy undermines trust in generated documents sent to clients, potentially leading to disputes over payments, accounting errors, and compliance issues with financial reporting standards. Furthermore, if the system is integrated with other business logic that relies on these totals for downstream processing, such as automated payment reconciliation or inventory deduction calculations, the integrity of those broader systems could be compromised. The ability to alter discount_val and tax fields independently also introduces risks related to revenue leakage or incorrect tax filing data.
This vulnerability aligns closely with CWE-20 Improper Input Validation, specifically regarding the failure to validate that input values are consistent with expected business logic constraints. It also relates to CWE-345 Insufficient Verification of Data Authenticity, as the system fails to verify that the summary totals correspond to the underlying line item data. In terms of attack vectors and tactics, this flaw facilitates actions categorized under MITRE ATT&CK techniques such as T1078 Valid Accounts, since exploitation requires authentication, and potentially impacts financial integrity which could be part of broader malicious objectives like resource hijacking or fraud if combined with other vulnerabilities.
To mitigate this risk, organizations running versions prior to 2.4.0 should upgrade immediately to the patched version where these validation checks have been implemented. For environments that cannot yet patch, it is crucial to restrict access to invoice and estimate creation endpoints to only those users who strictly require such privileges, adhering to the principle of least privilege. Additionally, implementing server-side recalculations for all financial totals before database persistence would provide a robust defense-in-depth measure. Regular audits of generated documents against their line items can also help detect any instances where this vulnerability may have been exploited in older deployments.