Threat Intelligence Database

Crater Invoice versions up to 6.0.6 have a path traversal vulnerability in the self-update API. Authenticated company owners can exploit this by submitting crafted ZIP archives with directory traversal sequences to the unzip endpoint. This allows writing arbitrary files outside the intended directory, including PHP files in the web-accessible public directory, potentially leading to remote code execution on the server.

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 weakness has been identified in crater-invoice-inc crater up to 6.0.6. This affects the function getFormattedString of the file app/Http/Requests/InvoicesRequest.php of the component Invoice Note Handler. Executing a manipulation of the argument notes can lead to cross site scripting. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.

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.

CriticalVulnerabilityUnited StatesGermanyUnited Kingdom+8#cve#cve-2024-55556