EUVD-2026-101613Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as ordinary staff user
-
DeliveryEnumerate sequential note IDs
-
ExploitCall /api/v1/notes/{id} across tenant
-
ExecutionRead, modify, or delete foreign note template
-
ImpactCross-company data disclosure and tampering
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires a valid authenticated staff account holding the ordinary 'view notes' or 'manage notes' ability (PR:L) on an InvoiceShelf instance prior to version 2.4.0, and the instance must host more than one company/tenant for cross-tenant impact to exist. Exploitation is limited by: needing an authenticated account (no anonymous access), the attacker only being able to reach reusable note templates (invoice/estimate/payment notes), not full financial records, and single-company/single-tenant deployments having no other tenant to victimize. Note IDs are sequential, so enumeration is trivial and no special configuration is required beyond the default multi-company capability. |
| Impact | This is a genuine but moderate-priority access-control flaw (CWE-639, Insecure Direct Object Reference) in multi-company InvoiceShelf deployments, not a high-CVSS-but-hollow issue - yet also not an urgent internet-wide emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) confirms network-reachable, low-complexity exploitation, but PR:L is the key limiter: the attacker must already hold a valid authenticated staff account with ordinary note abilities on the target instance, so this is an insider/cross-tenant privilege problem rather than anonymous remote compromise. No EPSS score, CISA KEV listing, or public POC was supplied in the intelligence, so there is no evidence of active exploitation or mass-scanning interest; the practical risk is targeted abuse within shared multi-tenant hosting. The underlying root cause is well-documented and confirmed directly from the vendor fix commit (NotesController passing only the generic ability without the route-bound Note, and NotePolicy not enforcing company_id), which raises confidence in the vulnerability's existence but does not elevate exploitation likelihood. Net: real and worth patching promptly for anyone running InvoiceShelf as a multi-company/SaaS tenant, low-to-negligible for single-tenant self-hosters. |
| Exploit ScenarioDerived | An authenticated staff user of one company on a shared multi-company InvoiceShelf instance (pre-2.4.0) calls the notes API with another company's sequential note ID and, because no company_id check occurs, reads, edits, or deletes that tenant's reusable invoice/estimate/payment note templates. No public exploit code was identified, but the attack requires only a trivial authenticated API request and ID enumeration, matching the low-complexity (AC:L), network (AV:N) CVSS profile. The vendor's own regression tests (GET/PUT/DELETE on a cross-company note expecting HTTP 403) demonstrate the exact exploitation path. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Cross-tenant access control bypass in InvoiceShelf prior to 2.4.0 lets an authenticated staff user holding only ordinary 'view notes' or 'manage notes' permissions read, modify, or delete another company's reusable invoice, estimate, and payment note templates by supplying a sequential note ID belonging to that tenant. The flaw is a classic insecure direct object reference (CWE-639) - the route-bound Note object is never handed to NotePolicy::viewNotes/manageNotes, so the policy checks only the generic ability and never validates the note's company_id, and the Note model carries no global company scope. Authentication is required (CVSS PR:L) and impact is confined to note templates rather than full financial records, but note IDs are sequential so enumeration is trivial; no public exploit code has been identified at time of analysis, and the vendor has released a fixed version (2.4.0).
RemediationAI
Upgrade InvoiceShelf to version 2.4.0, which contains the authorization fix in commit e432e4e62f5aa52238e3ff3fc37a0c78588eec47 and pull request InvoiceShelf/InvoiceShelf#661; the release is available at https://github.com/InvoiceShelf/InvoiceShelf/releases/tag/2.4.0 and the advisory at https://github.com/InvoiceShelf/InvoiceShelf/security/advisories/GHSA-85wc-38p4-2wqq should be reviewed before scheduling the upgrade. If immediate upgrade is not possible, reduce the attack surface by revoking the 'view notes' and 'manage notes' abilities from non-administrative staff roles, understanding the side effect that affected users will no longer be able to manage note templates at all; consider restricting the application to a single company during the interim, which removes any second tenant to victimize but changes how the instance is used. Additionally, monitor web-server and application logs for GET, PUT, and DELETE requests to /api/v1/notes/{id} returning HTTP 200 where the requesting user's company does not own the referenced note ID - sequential IDs make such probing visually obvious in access logs - and audit note rows for unexpected renames or deletions as evidence of prior exploitation. Note that inbound request filtering at a reverse proxy cannot reliably distinguish a legitimate note ID from a cross-tenant one, so it is a weak compensating control compared with patching.
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 and expense-tracking application built around a multi-tenant 'company' model, where a single installation can host multiple companies and users are attached to one or more of them. The vulnerability class is CWE-639, Authorization Bypass Through User-Controlled Key: the NotesController methods show, update, and destroy call $this->authorize('view notes') / $this->authorize('manage notes') without passing the route-bound Note model, so the Bouncer-based NotePolicy evaluates only a coarse ability check and never reaches a per-object ownership test. The Note model itself has no global company scope, so Eloquent resolves any note ID in the database regardless of tenant. The upstream fix (commit e432e4e62f5aa52238e3ff3fc37a0c78588eec47) changes the policy signatures to accept an optional Note ($user, ?Note $note = null) and adds a tenant-isolation check, returning true only when $note is null or $user->hasCompany($note->company_id); the controllers were updated to pass the bound $note into the authorize call. The same commit also hardened ConvertEstimateController by authorizing 'view' on the source estimate before conversion, and scoped bulk user deletion in UsersController to the acting company via User::whereCompany()->whereIn('id', ...), indicating this was a broader tenant-isolation sweep rather than an isolated patch.
Know when Laravel gets its next vulnerability
- 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
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L
Authenticated staff user over the network with trivial ID enumeration (PR:L, AC:L, AV:N); impact confined to note templates, so confidentiality, integrity, and availability are each Low rather than High.
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. Prior to version 2.4.0, InvoiceShelf NotesController::show, NotesController::update, and NotesController::destroy authorize only the generic view notes or manage notes ability and do not pass the route-bound Note to NotePolicy::viewNotes or NotePolicy::manageNotes, so neither method checks the target note's company_id. Because the Note model has no global company scope, an authenticated staff user with ordinary note abilities can select another company's sequential note identifier and read, modify, or delete its reusable invoice, estimate, and payment note templates. This issue is fixed in version 2.4.0.
Technical POC Analysis
CWE-639 (Authorization Bypass Through User-Controlled Key, cross-tenant BOLA/IDOR), also CWE-862.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
InvoiceShelf, the invoicing and billing platform used to manage company financial documents, contains a cross-tenant access control flaw (CVE-2026-55382) that allows any authenticated staff member with routine note permissions to read, alter, or delete another organization's reusable invoice, estimate, and payment note templates. Because note identifiers are sequential, a low-privilege internal user can enumerate records belonging to other customers with minimal effort, creating multi-tenant data confidentiality, integrity, and trust exposure. Leadership should care because this is a tenant-isolation failure in a system that handles billing content, where even limited data leakage can trigger customer notification obligations, contractual breach claims, and erosion of confidence in the platform's segregation guarantees.
Apply vendor patch. Interim mitigations pending upgrade to 2.4.0 include restricting or disabling the 'view notes' and 'manage notes' permissions for non-essential accounts, limiting note-route access to trusted single-tenant users, and monitoring for anomalous cross-tenant note ID enumeration.
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.
In Laravel framework through 5.5.21, remote attackers can obtain sensitive information (such as externally usable passwo
Laravel Livewire v3 through v3.6.3 contains a critical remote code execution vulnerability (CVE-2025-54068, CVSS 9.8) th
LaRecipe versions prior to 2.8.1 contain a Server-Side Template Injection (SSTI) vulnerability that can lead to Remote C
File upload bypass in FreeScout 1.8.206 — patch bypass for CVE-2026-27636. PoC and patch available. CVSS 10.0.
Remote code execution in FreeScout prior to version 1.8.206 allows authenticated users to upload `.htaccess` files that
In Laravel Framework through 5.5.40 and 5.6.x through 5.6.29, remote code execution might occur as a result of an unseri
Dokans SaaS e-commerce platform v3.9.2 has a CVSS 10.0 authentication bypass allowing unauthenticated attackers to obtai
Predictable password reset tokens in FreeScout help desk before 1.8.206. Weak random number generation allows attackers
Bagisto eCommerce platform before 2.3.10 is vulnerable to server-side template injection (SSTI) through customer address
Bagisto eCommerce platform (2.3 branch before 2.3.10) leaves installation API routes active after setup, allowing unauth
A vulnerability was found in laravel 5.1 and classified as problematic. Rated critical severity (CVSS 9.8), this vulnera
Laravel TokenGuard authentication bypass is a genuine high-priority issue, not an inflated CVSS score: unauthenticated a
Exploit-DB