EUVD-2026-53194
GHSA-j2xj-x8wc-f6xg
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
PR:L for any tenant user; A:H raised from provided A:L because cascading deletion permanently destroys invoice and payment records.
Primary rating from Vendor (TuranSec).
CVSS VectorVendor: TuranSec
Lifecycle Timeline
5DescriptionCVE.org
Crater isolates data per company_id, and its Invoice/Estimate/Payment/Expense policies enforce both a Bouncer ability check and $user->hasCompany($model->company_id). CustomerPolicy's view/update/delete methods omit the company-ownership check entirely, checking only the blanket ability. Route-model-bound customer lookups and the bulk Customer::deleteCustomers() method are similarly unscoped (self::find($id) with no company filter). Any authenticated user of one company can read, reassign (steal), or delete another company's customer records, with deletion cascading to that customer's invoices and payments.
AnalysisAI
Cross-company customer record access in Crater 6.0.6 exposes a multi-tenant authorization flaw where any authenticated tenant user can read, modify, or permanently delete customer records owned by other companies. The CustomerPolicy authorization class omits the company_id ownership check that all other resource policies (Invoice, Estimate, Payment, Expense) correctly enforce, and route-model-bound customer lookups use unscoped queries (self::find($id)) that return records regardless of company ownership. No public exploit has been identified at time of analysis; the CVSS 8.3 (High) score reflects straightforward network-reachable exploitation by any low-privilege authenticated user, with cascading destruction of financial records as the worst-case availability impact.
Technical ContextAI
Crater is a multi-tenant open-source invoice management web application (CPE: cpe:2.3:a:crater-invoice:crater:*:*:*:*:*:*:*:*) built on the Laravel PHP framework, using the Bouncer library for role and ability authorization. The application enforces multi-tenancy by scoping resource access to a user's associated company via a $user->hasCompany($model->company_id) check. This guard is correctly applied in policies for Invoices, Estimates, Payments, and Expenses. However, the CustomerPolicy class - governing view, update, and delete operations on customer records - checks only the blanket Bouncer ability without the company_id ownership guard. This omission extends to route-model binding, where customer IDs are resolved using the unscoped Customer::find($id), and to the bulk-delete helper Customer::deleteCustomers(), which similarly performs no company-scoped lookup. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key), a form of IDOR where an attacker supplies an arbitrary object identifier and the authorization layer fails to validate that the object belongs to the requester's tenant.
RemediationAI
No vendor-released patch has been identified at time of analysis; the sole reference points to the upstream repository at https://github.com/crater-invoice/crater without a tagged fix release or dedicated security advisory. Operators running multi-tenant Crater instances should immediately restrict access to the application to known, trusted IP ranges via network-level controls, reducing the pool of potential authenticated attackers - this does not eliminate the flaw but raises the bar from internet-scale to organization-scale exploitation. Disabling multi-company functionality entirely until a patch is available eliminates cross-tenant exposure at the cost of the core multi-tenancy feature. Code-level remediation requires adding $user->hasCompany($model->company_id) to CustomerPolicy's view, update, and delete methods, replicating the pattern already used in Invoice/Estimate/Payment/Expense policies; additionally, all Customer model lookups must be scoped to the authenticated user's company (e.g., Customer::where('company_id', $user->company_id)->findOrFail($id)) rather than the global self::find($id), and Customer::deleteCustomers() must apply the same scoping. Monitor the upstream GitHub repository for a tagged patch release and apply promptly.
Unrestricted Upload of File with Dangerous Type in GitHub repository crater-invoice/crater prior to 6.0.6. Rated high se
/api/v1/company/upload-logo in CompanyController.php in crater through 6.0.6 allows a superadmin to execute arbitrary PH
Insecure deserialization of not validated module file in GitHub repository crater-invoice/crater prior to 6.0.6. Rated h
Business Logic Errors in GitHub repository crater-invoice/crater prior to 6.0.5. Rated medium severity (CVSS 6.5), this
Cross-Site Request Forgery (CSRF) in GitHub repository crater-invoice/crater prior to 6.0.4. Rated medium severity (CVSS
Cross-site scripting in Crater invoice application (up to v6.0.6) allows an authenticated attacker to inject malicious s
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today