Gustavo Novaro

An authorization flaw in the user API allows a user with a basic role to access accounts of other users within the same company, including those with higher privileges. In versions 3.5.0 and later, this also allows the deletion of such accounts. The issue exists because the endpoints 'GET /api/user/{id}' and 'DELETE /api/user/{id}' only verify the validity of a JSON Web Token via the `auth:api` middleware without checking specific permissions, policies, or roles in the `UserReadController::read()` and `UserDeleteController::delete()` functions. While access is generally scoped by company, the deletion process bypasses company verification if the authenticated user belongs to `Company::DEFAULT COMPANY`, enabling a basic user in that company to delete any account across the entire installation. This can lead to the exposure of personal data, such as email addresses, telephone numbers, postal addresses, and IBANs, and the potential removal of the last administrative account of a company.

Cross-Site Request Forgery (CSRF) occurs in the `OrderConfirmController` at the 'GET /order/confirm/{order number}' endpoint. This issue arises because the `Route::get` declaration allows state-changing actions to bypass the `VerifyCsrfToken` middleware, which only enforces tokens on POST, PUT, PATCH, and DELETE requests. Since session cookies with `SameSite=Lax` are included in top-level cross-site navigation, an unauthenticated attacker can trick an authenticated user into clicking a crafted link to trigger the `confirm()` function. This transitions orders from pending to confirmed without authorization. Additionally, because the `order number` variable uses sequential integers, an attacker can enumerate and confirm all existing orders.

An unrestricted file upload issue exists in the product photo upload feature. An authenticated user with the create product permission, such as the Seller role, can execute arbitrary JavaScript within the application origin. The system validates files based on magic bytes (content signatures) and only rejects a specific list of PHP extensions. However, the `ProductSaveController::save()` function uses the client-supplied extension when saving the file to the public web root. Consequently, a file containing an image header but using an HTML extension can be uploaded to `public/asset/upload/product/` and served as `text/html`, resulting in stored cross-site scripting (XSS), where a malicious script is permanently stored on the server and executed in the browser of users who view the file.

An authorization bypass exists in the supplier API that allows an authenticated user to read, modify, and reassign supplier records belonging to other companies to their own. This is achieved by sending a PUT request to the '/api/supplier/{id}' endpoint and manipulating the `company id` variable within the request body.

An issue exists in the company logo upload feature where the system fails to restrict the upload of dangerous file types. An authenticated user with permissions to create or update companies can upload an SVG document containing an embedded script element, leading to the execution of arbitrary JavaScript within the application origin.

An authorization bypass exists in the transaction API that allows an authenticated user to read financial records belonging to other companies on the same instance. This occurs because the system fails to implement company scoping or permission checks when processing requests. The issue is triggered via an incremented identifier in the GET '/api/transaction/{id}' endpoint, specifically affecting the `id` variable.

An authorization bypass exists in the transaction save endpoint. A user with transaction and accounting creation permissions can disclose sensitive banking information from another company, including the bank account name, bank name, and the last four digits of a card. This occurs when a `bank account id` or `bank card id` belonging to another company is provided in the POST '/transaction/save' endpoint, as the system persists and renders the data without verifying company ownership.

The human resources component contains hard-coded credentials. Unauthenticated remote attackers can authenticate as any employee onboarded through the standard flow by providing only the employee's email address. This occurs because the employee save controller defaults to the password `changeme` and the onboarding form does not include a password field.

An authorization bypass exists in the payroll module where the listing query is not scoped to the caller's company and the employee identifier is validated for global existence rather than company membership. This allows authenticated users with read payroll permissions to view salary and banking details of employees from any other company within the instance. Additionally, users with create payroll permissions can create payroll records attributed to employees of other companies.

An authorization bypass exists in the product management component. Authenticated users can access sensitive data, including price, cost, stock, SKU, and barcode, belonging to other companies. Additionally, users can hijack products by reassigning the `company id` using the product's numeric identifier. This occurs because the `ProductUpdateController` does not extend `MainController`, resulting in a lack of authentication checks on the read endpoint. Furthermore, the `ProductRepository::save()` function uses `Product::find($data['id'])` to retrieve records without verifying if the product belongs to the authenticated user's company before updating the `company id` variable.

An authorization bypass exists in the ticket management component. Authenticated users can access, modify, or delete tickets belonging to other companies using the ticket's numeric identifier. This occurs because read and save operations do not restrict queries to the authenticated user's company. Additionally, the delete controller uses a generic `IlluminateHttpRequest` instead of the `TicketDeleteRequest`, which fails to enforce necessary permissions. This allows users to read full ticket content (title, description, and attachments), hijack tickets by reassigning the `company id` variable, or delete tickets without authorization.

An authorization bypass exists in the contact management component. Authenticated users can overwrite contact data belonging to other companies or download personal data as a vCard by manipulating the contact's numeric identifier. This occurs because the save and export operations retrieve records without restricting the query to the company associated with the authenticated user.

The permission management component contains a flaw where the permission save endpoint does not perform authorization checks. This allows any authenticated user to grant any role, including their own, the full set of application permissions by sending a crafted POST request to the endpoint, which then synchronizes the submitted permissions to the specified role.

Authenticated users with permissions to create or update leads can execute arbitrary JavaScript within the application origin. This occurs in the lead index view when HTML markup stored in the lead name field is rendered using Blade's unescaped output directive and placed inside a JavaScript string literal within an `onclick` attribute.

The email module contains a stored cross-site scripting issue. A remote, authenticated user with low privileges can execute arbitrary JavaScript in the browser of another user, including administrators, by storing a malicious payload in an email body. This occurs because the email body is persisted without sanitization and rendered unescaped using `{!! $email->body !!}` when the recipient opens the message, which can lead to session compromise and account takeover.

An Insecure Direct Object Reference (IDOR) exists in the `DeleteNotificationController::delete()` method at the `GET /notification/delete/{id}` endpoint. This flaw allows any authenticated user to delete notifications belonging to any other user in the system, regardless of their company or permissions. The issue occurs because the controller uses `Notification::findOrFail($id)` to retrieve records without validating the `user id` or `company id` ownership. Since notification identifiers are sequential, an attacker can iterate through IDs to systematically delete notifications, preventing users from seeing ticket alerts, task assignments, and other system events.

An authorization bypass exists in the Order and OrderItem REST API controllers. A remote, authenticated user can read, modify, and delete orders and order items belonging to other companies (tenants) by providing a sequential numeric `id` to the following endpoints: - 'GET /api/order/{id}' - 'PUT /api/order/{id}' - 'GET /api/order-item/{id}' - 'PUT /api/order-item/{id}' - 'DELETE /api/order-item/{id}' This occurs because the controllers use the `Order::find($id)` and `Item::find($id)` functions to resolve records without restricting the search to the authenticated user's company.

An authorization flaw exists in the `BankAccountListController` (app/Http/Controllers/Api/BankAccount/BankAccountListController.php) at the GET '/api/bank-account' endpoint. A remote, authenticated attacker with a low-privileged role, such as User, can read arbitrary bank account records belonging to their company. This occurs because the API route is protected only by the `auth:api` middleware and lacks a permission gate, unlike the web route which enforces the `can('read bank')` check. The handler uses `Account::where('company id', Auth::user()->company id)->get()`, which only applies company scoping without verifying the user's role or permissions. This leads to the unauthorized disclosure of sensitive banking data, including IBAN, SWIFT/BIC, and account identifiers.

An authorization bypass exists in the Excel import handlers (CustomerImport, LeadImport, and ProductImport). A remote, authenticated user can create customer, lead, and product records within another company's tenant by uploading a spreadsheet to the POST '/customer/import/excel/save' endpoint. The system maps the `company id` variable directly from the uploaded file without verifying if it matches the authenticated user's company, allowing the `company id` to be controlled by the user.

An authorization bypass exists in the `CalendarDeleteEventController` (app/Http/Controllers/Calendar/CalendarDeleteEventController.php) via the GET '/calendar/event/delete/{id}' endpoint. A remote, authenticated attacker can delete arbitrary calendar events belonging to other users by manipulating the `{id}` path parameter. This occurs because the delete handler uses the `Calendar::find($id)->delete()` function without performing ownership checks, such as scoping by `user id` or `company id`, leading to unauthorized destruction of data across the platform.