EUVD-2026-53315
GHSA-2467-45mc-2xp5
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
Network API requires only a valid low-privilege account; no complexity or interaction needed; full read/write access to cross-tenant notes yields C:H/I:H, with A:L reflecting deletion but no broader service disruption.
Primary rating from Vendor (309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c).
CVSS VectorVendor: 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c
Lifecycle Timeline
2DescriptionCVE.org
Crater's NotePolicy checks only a blanket Bouncer ability (manage-all-notes / view-all-notes) with no company-ownership comparison, unlike InvoicePolicy and other sibling policies which additionally verify $user->hasCompany($model->company_id). NotesController's show(), update(), and destroy() actions authorize via $this->authorize('view notes'/'manage notes') without passing the target Note model, and Note's company-scoping (scopeWhereCompany) is applied only in the list endpoint, not in show/update/destroy. Any authenticated user of one company can read, edit, or delete another company's notes by ID. This is a distinct finding from the previously reported CustomerPolicy company-ownership omission (a different policy class and controller).
AnalysisAI
Cross-company note access in the Crater open-source invoice platform allows any authenticated user to read, modify, or delete notes belonging to an entirely different company by supplying a foreign note ID in the API. NotePolicy omits the company-ownership verification (hasCompany) that sibling policies such as InvoicePolicy correctly enforce, and NotesController's show(), update(), and destroy() actions call authorize() without passing the target Note model instance, meaning no per-resource ownership check ever executes. No public exploit has been identified at time of analysis, but the CVSS 8.3 rating reflects that the technique requires only sequential ID enumeration against a standard multi-tenant deployment - a low-effort, high-impact path to cross-tenant data exfiltration and tampering.
Technical ContextAI
Crater is an open-source Laravel-based invoice management application (https://github.com/crater-invoice/crater) designed to support multi-tenant operation where multiple companies share a single installation. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): note records are keyed by sequential integer IDs that users can supply directly in API routes, and the authorization layer never validates that the supplied ID belongs to the caller's company. Laravel's policy authorization is invoked as $this->authorize('view notes') rather than $this->authorize('view notes', $note), so NotePolicy receives no model instance and cannot perform a per-resource ownership comparison. The query scope scopeWhereCompany, which would filter results to the caller's tenant, is applied only in the index/list endpoint and is absent from show, update, and destroy. The CPE for this product is not formally registered in NVD; affected versions are unconfirmed from available data.
RemediationAI
The primary fix requires two coordinated code changes: first, update NotePolicy to include a company-ownership predicate (e.g., $user->hasCompany($model->company_id)) in both the view-notes and manage-notes checks, mirroring the pattern already present in InvoicePolicy and other sibling policies; second, update NotesController's show(), update(), and destroy() methods to pass the resolved Note model instance to $this->authorize() so the policy can perform per-resource checks. The scopeWhereCompany query scope should also be applied consistently in show/update/destroy queries as a defense-in-depth measure. No exact patched version is confirmed from available data - monitor https://github.com/crater-invoice/crater for fix commits. As a compensating control prior to patching, restrict Crater to single-tenant deployments (one company per instance) or apply network-layer access controls to limit which authenticated users can reach the notes API endpoints, accepting the operational trade-off of reduced multi-tenancy functionality.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today