CVE-2026-55386 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 passes the authenticated user's orderByField query parameter into Laravel orderBy calls in Invoice::scopeApplyFilters without restricting the value to column identifiers. A crafted SQL expression can therefore enter the ORDER BY clause across invoice and other list endpoints, enabling boolean-based blind extraction of database information. This issue is fixed in version 2.4.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
InvoiceShelf serves as an open-source solution for managing financial records, including expense tracking, payment monitoring, and the generation of professional invoices and estimates. The application relies on Laravel, a popular PHP web framework, to handle backend logic and database interactions. A critical security flaw was identified in versions prior to 2.4.0 within the Invoice::scopeApplyFilters method. This vulnerability stems from improper input validation regarding the orderByField query parameter passed by authenticated users. Instead of restricting this parameter to predefined column identifiers or whitelisting allowed values, the application directly interpolates user-supplied data into Laravel's orderBy calls.
The technical nature of this flaw constitutes an Insecure Direct Object Reference combined with SQL Injection characteristics, specifically classified under CWE-89 for Improper Neutralization of Special Elements used in an SQL Command and CWE-20 for Improper Input Validation. Because the application fails to sanitize or validate the input before using it in a database query structure, attackers can inject arbitrary SQL syntax into the ORDER BY clause. Unlike typical WHERE-based injection attacks that manipulate data retrieval conditions, this vulnerability allows manipulation of how results are sorted, which is often less monitored by standard web application firewalls and security controls due to its perceived lower risk profile.
The operational impact of this vulnerability is severe for authenticated users who have access to invoice listing endpoints or other list views within the InvoiceShelf interface. By crafting a malicious SQL expression in the orderByField parameter, an attacker can exploit boolean-based blind extraction techniques. This method involves sending queries that return different results based on whether a specific condition evaluates to true or false, allowing the attacker to infer data character by character from the underlying database. Since this occurs within the context of authenticated access, the attack requires valid credentials but does not require high privilege levels beyond basic user access, making it accessible to a wider range of potential adversaries who may have compromised low-level accounts.
This vulnerability aligns with MITRE ATT&CK technique T1078, Valid Accounts, as exploitation relies on existing authentication, and can be categorized under data exfiltration techniques where structured query language injection is used to extract sensitive information such as user credentials, financial records, or other proprietary business data stored in the database. The ability to perform blind extraction means that even if error messages are suppressed by default Laravel configurations, an attacker can still reconstruct significant portions of the database schema and content through time-based or boolean-based side channels derived from response times or status codes.
To mitigate this vulnerability, organizations running InvoiceShelf must upgrade immediately to version 2.4.0 or later, where the developers have implemented proper input validation for the orderByField parameter. For environments that cannot be upgraded instantly due to operational constraints, defensive measures should include implementing a strict whitelist of allowed column names on the server side before passing any user input to database query builders. Additionally, deploying Web Application Firewalls with rules capable of detecting anomalous SQL syntax in ORDER BY clauses can provide an additional layer of defense. Regular security audits and code reviews focusing on dynamic query construction practices are recommended to prevent similar injection flaws in other parts of the application logic.