EUVD-2026-101609Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege tenant user
-
DeliveryEnumerate foreign company record IDs
-
ExploitSubmit bulk-delete with those IDs
-
ExecutionValidator skips tenant ownership check
-
ImpactCross-company records permanently deleted
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Access control enforcement
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated InvoiceShelf account with membership in at least one company (PR:L) AND a multi-tenant deployment where more than one company shares the same instance - single-company self-hosted installations have no cross-company data to target. The attacker must supply another company's record identifiers to one of the affected bulk-delete endpoints whose validators (DeleteCustomersRequest, DeleteEstimatesRequest, DeleteExpensesRequest, DeleteInvoiceRequest, DeleteItemsRequest, DeletePaymentsRequest, DeleteUserRequest) check existence but not tenant ownership; numeric IDs may be guessable/enumerable. LIMITING FACTORS: valid authentication is mandatory (not unauthenticated), the flaw is inert on default single-tenant installs, and only versions 2.3.3 and earlier are affected (patched in 2.4.0). |
| Impact | This is a genuine authorization (IDOR / broken access control, CWE-284) flaw rather than a high-CVSS-but-low-real-risk issue, but its severity is conditional. The GitHub-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VC:N/VI:H/VA:H) scores 7.2 High: network-reachable, low attack complexity, no user interaction, but requiring low-level authentication (PR:L), with high integrity and availability impact (destructive cross-company record deletion) and no confidentiality impact per the vendor. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so exploitation remains theoretical in the data available: no public exploit identified at time of analysis. The practical risk is driven almost entirely by deployment model - the flaw is only meaningfully exploitable on multi-tenant instances where multiple companies share one InvoiceShelf installation; single-company self-hosted deployments have no foreign tenant data to destroy. CONFLICT TO VERIFY: the vendor CVSS sets VC:N (no confidentiality impact), but the fix commit also adds tenant checks to estimate conversion (ConvertEstimateController) and note retrieval (NotesController/NotePolicy), which are read/disclosure paths - this suggests the official scoring understates a confidentiality (information-disclosure) dimension and should be verified against the GHSA advisory. |
| Exploit ScenarioDerived | An authenticated low-privilege user of one company (tenant) on a shared InvoiceShelf instance submits a bulk-delete API request (e.g. /api/v1/users/delete or the customer/invoice/estimate/expense/item/payment delete endpoints) containing record identifiers belonging to a different company. Because the request validators confirm the IDs exist but do not bind them to the caller's company_id, the records of the victim company are deleted. No public exploit code was provided, but the attack requires only a crafted API request with guessed or enumerated numeric IDs. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Cross-company record deletion in InvoiceShelf 2.3.3 and earlier allows an authenticated user with membership in any one company to destroy data belonging to other tenants on the same instance. The bulk-delete validators (DeleteCustomersRequest, DeleteEstimatesRequest, DeleteExpensesRequest, DeleteInvoiceRequest, DeleteItemsRequest, DeletePaymentsRequest and DeleteUserRequest) verify that submitted identifiers exist but do not consistently bind them to the caller's company_id, so an attacker who supplies a foreign numeric ID can delete customers, estimates, expenses, invoices, items, payments or user accounts outside their own tenant. Exploitation requires a valid account (PR:L) and a multi-tenant deployment; single-company self-hosted installs have no cross-tenant data to target. No public exploit code or active exploitation was identified at time of analysis, and the vendor released a fix in 2.4.0.
RemediationAI
Upgrade to InvoiceShelf 2.4.0 (https://github.com/InvoiceShelf/InvoiceShelf/releases/tag/2.4.0), which is the vendor-released patch containing the tenant-scoping fix; if a full upgrade is not immediately possible, the minimal targeted change is the upstream commit e432e4e62f5aa52238e3ff3fc37a0c78588eec47 (PR https://github.com/InvoiceShelf/InvoiceShelf/pull/661), which adds a User::whereCompany()->whereIn('id', $request->users) scope before User::deleteUsers and instantiates the NotePolicy and estimate authorization checks against the specific model rather than the class. Until patched, restrict exposure of the admin API - require that the application sit behind authentication plus network ACLs or a VPN so only trusted staff reach /api/v1/users/delete and the bulk-delete routes, accepting that this does not stop a malicious or compromised legitimate tenant account; disable or hide the bulk-delete UI actions if the deployment tolerates the operational inconvenience; and treat cross-tenant ID enumeration as the trigger, so enabling request logging and alerting on delete requests whose IDs fall outside the caller's own company is a useful detection control, at the cost of added log volume and tuning effort. Additional compensating controls specific to this flaw include enforcing company scoping in a global Eloquent scope or a middleware that filters every inbound ID list against the authenticated user's company_id, which fixes the root cause class but risks breaking legitimate cross-company administrative workflows if the application is later used by super-admin or support roles. Note that the same patch also hardens note read/update/delete and estimate-to-invoice conversion, so partial cherry-picking of only the delete endpoints leaves those related authorization gaps open. Consult the advisory at https://github.com/InvoiceShelf/InvoiceShelf/security/advisories/GHSA-wxrv-73x6-8r62 for the vendor's own guidance, and after upgrading, review historical delete activity across tenants to determine whether the flaw was already exercised.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
InvoiceShelf is a Laravel-based invoicing, expense and payment tracking application built around a multi-tenant data model in which nearly every record carries a company_id and users are attached to one or more companies. The flaw is a classic Insecure Direct Object Reference / broken tenant-isolation problem in the CWE-284 (Improper Access Control) family: the affected FormRequest validator classes were written to confirm that the IDs in a bulk-delete payload correspond to existing rows, but they omitted the ownership predicate (a company_id scope against the acting user), and the controller actions then passed the raw request array straight into the model delete helper. Because authorization was expressed as coarse ability checks ('manage notes', 'view notes', 'manage users') without a resource instance argument, Laravel's policy layer had no model to compare against the caller's tenant, so the check could never distinguish 'this record exists' from 'this record is mine'. The upstream fix (commit e432e4e62f5aa52238e3ff3fc37a0c78588eec47, PR #661) addresses this at three levels: it scopes candidate IDs with User::whereCompany()->whereIn('id', ...) before deletion in UsersController::delete, it changes NotePolicy::manageNotes/viewNotes to accept an optional Note and return $user->hasCompany($note->company_id), and it adds $this->authorize('view', $estimate) to ConvertEstimateController so an estimate from another company cannot be converted into an invoice. That last change matters beyond the CVE description: it shows the same missing-tenant-scoping pattern also affected note read/update/delete and estimate-to-invoice conversion, and the accompanying feature tests (403 assertions on cross-company note retrieval, update, delete, estimate conversion and bulk user deletion) document the intended isolation contract. The CVSS 4.0 vector supplied (AV:N/AC:L/AT:N/PR:L/UI:N with VI:H/VA:H but VC:N/SC:N/SI:N/SA:N) is consistent with integrity and availability loss confined to other tenants' records on the same instance rather than disclosure.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Authenticated low-privilege user (PR:L) over the network with no interaction can delete another company's records; missing tenant check yields high integrity and availability impact, with no confidentiality impact from the delete itself.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
InvoiceShelf is an open-source web & mobile app that helps track expenses, payments and create professional invoices and estimates. In version 2.3.3 and earlier, InvoiceShelf bulk-delete request validation accepts record identifiers without consistently binding them to the authenticated user's company_id. The affected DeleteCustomersRequest, DeleteEstimatesRequest, DeleteExpensesRequest, DeleteInvoiceRequest, DeleteItemsRequest, DeletePaymentsRequest, and DeleteUserRequest validators check that identifiers exist but do not consistently check tenant ownership. An authenticated user can submit another company's identifier and delete cross-company records. This vulnerability is fixed in 2.4.0.
Technical POC Analysis
CWE-284 (Improper Access Control).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
InvoiceShelf deployments running 2.3.3 or earlier in a multi-tenant configuration let any user with a valid account in a single tenant permanently destroy invoices, estimates, expenses, customers, items, payments, and user accounts belonging to every other organization on the same instance. Because the flaw needs only an ordinary low-privilege login rather than administrative access, a single hostile or careless tenant can irreversibly wipe the financial records of partners and competitors, turning a routine billing platform into a cross-customer data-destruction risk. Leadership should care most about the loss of billing-record integrity, the near-impossibility of recovery without independent backups, and the contractual and regulatory exposure of hosting multiple customers on shared infrastructure.
Apply vendor patch (upgrade to 2.4.0 or later).
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB