CVE-2026-55610: InvoiceShelf has cross-company user read/update IDOR that enables cross-tenant account takeover
InvoiceShelf is an open-source web & mobile app that helps track expenses, payments and create professional invoices and estimates. Prior to version 2.4.1, in InvoiceShelf's multi-company installations, any user who is an Owner of one company can read and overwrite any user account in any other company on the same installation. GET/PUT /api/v1/users/{user} resolves the target User by global primary key, and UserPolicy checks only that the requester owns their own header-company — it never verifies that the target user belongs to that company. This allows cross-tenant disclosure of user data and full account takeover (email/password overwrite + company re-assignment). Version 2.4.1 fixes the issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
InvoiceShelfto a version that resolves this vulnerability.Fixed in 2.4.1
Event History
Frequently Asked Questions
Which deployments are exposed?
Multi-company InvoiceShelf installations running versions before 2.4.1 are affected. A user must be an Owner of at least one company on the same installation.
What does an attacker need to exploit this issue?
The attacker needs an authenticated Owner account for any company in the installation and the global primary key of a target user. No user interaction is required.
What can an attacker do after exploiting it?
An Owner from one company can read user data from another company and overwrite the target account through the user API. This includes changing the target email and password and reassigning the account's company, enabling account takeover.
How can I determine whether my installation is affected?
Check whether the installation supports multiple companies and is running a version earlier than 2.4.1. Affected behavior is present when GET or PUT requests to /api/v1/users/{user} allow an Owner of one company to access or modify a user belonging to another company.
What should be done if immediate patching is not possible?
The provided information does not identify a workaround. Restricting access to Owner accounts and monitoring or limiting requests to /api/v1/users/{user} may reduce exposure, but the issue is fixed in version 2.4.1.