Vulnerabilidades do Roskus Prospero Flow CRM

Authorization Bypass Through User-Controlled Key in the transaction API in Roskus Prospero Flow CRM 5.0.0 through 5.3.5 allows an authenticated user to read the transactions of other companies on the same instance via an incremented identifier in GET /api/transaction/{id}, which is resolved without company scoping and without any permission check.

Authorization Bypass Through User-Controlled Key in the payroll module in Roskus Prospero Flow CRM before 5.15.10 allows authenticated users holding the read payroll permission to view the salary and banking details of employees of any other company in the instance, and users holding the create payroll permission to create payroll records attributed to another company's employees, because the listing query is not scoped to the caller's company and the employee identifier is validated for global existence rather than company membership

Missing Authorization and Authorization Bypass Through User-Controlled Key in the product management component in Roskus Prospero Flow CRM before 5.4.7 allows authenticated users of any company to read the full sensitive data (price, cost, stock, SKU, and barcode) of another company's product and to hijack that product by reassigning its company_id, via the product's numeric identifier, because `ProductUpdateController` did not extend `MainController` and therefore required no authentication check on the read endpoint, and `ProductRepository::save()` retrieved the record via `Product::find($data['id'])` without constraining the query to the authenticated user's company before overwriting its company_id.

Authorization Bypass Through User-Controlled Key in the ticket management component in Roskus Prospero Flow CRM before 5.4.9 allows authenticated users of any company to read the full content (title, description, and attachments) of tickets belonging to another company, to hijack another company's tickets by reassigning their company_id, and to delete another company's tickets without any authorization check, via the ticket's numeric identifier, because the read and save operations retrieve the record without constraining the query to the authenticated user's company, and the delete controller type-hints a generic Illuminate\Http\Request instead of the TicketDeleteRequest that would enforce the required permission.

Authorization Bypass Through User-Controlled Key in the contact management component in Roskus Prospero Flow CRM before 5.4.8 allows authenticated users of any company to blindly overwrite the contact data of another company and to download that contact's personal data as a vCard via the contact's numeric identifier, because the save and export operations retrieve the record without constraining the query to the authenticated user's company.

Missing Authorization in the permission management component in Roskus Prospero Flow CRM before 5.2.1 allows any authenticated user to grant any role, including their own, the complete set of application permissions via a crafted POST request to the permission save endpoint, which performs no authorization check before synchronizing the submitted permissions to the specified role.

Stored Cross-site Scripting (CWE-79) in the email module in Roskus Prospero Flow CRM before 5.4.4 allows a remote, authenticated low-privileged user to execute arbitrary JavaScript in another user's browser, including administrators, leading to session compromise and account takeover, via a payload stored in an email body that is persisted without sanitization and rendered unescaped with {!! $email->body !!} when the recipient opens the message.

Missing Authorization (CWE-862) in BankAccountListController (app/Http/Controllers/Api/BankAccount/BankAccountListController.php), exposed at GET /api/bank-account, in Prospero Flow CRM <5.5.3, which allows a remote, authenticated attacker holding a low-privileged role (e.g. the "User"/"Usuario" role) to read arbitrary bank account records belonging to their company by sending an authenticated request to the endpoint with a valid bearer token, because the API route is protected only by the auth:api middleware and carries no permission gate, unlike the equivalent web route, which enforces can('read bank'), and the handler resolves records with Account::where('company_id', Auth::user()->company_id)->get(), performing only company scoping and no role or permission check before returning the data. This results in the unauthorized disclosure of sensitive banking information (e.g. IBAN, SWIFT/BIC, account identifiers) to users who should not have access to it.