Threats affecting pkg:github/crater-invoice/crater

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 ->hasCompany(->company_id). Any authenticated user of one company can read, edit, or delete another company's notes by ID.

Crater isolates data per company_id, and its Invoice/Estimate/Payment/Expense policies enforce both a Bouncer ability check and ->hasCompany(->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 with no company filter).

A vulnerability in Crater Invoice allows an unauthenticated attacker with knowledge of the APP_KEY to achieve remote command execution on the server by manipulating the laravel_session cookie, exploiting arbitrary deserialization through the encrypted session data. The exploitation vector of this vulnerability relies on an attacker obtaining Laravel's secret APP_KEY, which would allow them to decrypt and manipulate session cookies (laravel_session) containing serialized data. By altering this data and re-encrypting it with the APP_KEY, the attacker could trigger arbitrary deserialization on the server, potentially leading to remote command execution (RCE). The vulnerability is primarily exploited by accessing an exposed cookie and manipulating it using the secret key to gain malicious access to the server.