CVE-2026-59235 in Prospero Flow CRM
Summary
by MITRE • 07/15/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/15/2026
The vulnerability described represents a critical authorization flaw classified as CWE-862, which specifically addresses missing authorization checks in software systems. This weakness occurs when an application fails to properly verify whether an authenticated user has the necessary permissions to access specific resources or perform certain operations. In the context of Prospero Flow CRM versions prior to 5.5.3, this vulnerability manifests within the BankAccountListController component located at app/Http/Controllers/Api/BankAccount/BankAccountListController.php. The exposed API endpoint at GET /api/bank-account serves as an attack vector that allows malicious actors with minimal privileges to bypass intended access controls and obtain sensitive financial information.
The technical implementation of this vulnerability stems from the inconsistent security enforcement between the application's web interface and its corresponding API endpoints. While the web route properly implements permission gates through the can('read bank') check, the API endpoint relies solely on the auth:api middleware for authentication without any additional authorization validation. This discrepancy creates a dangerous gap in the security model where authenticated users can access resources beyond their intended scope simply by exploiting the lack of proper permission verification. The controller's implementation directly queries database records using Account::where('company_id', Auth::user()->company_id)->get() which performs only company-level scoping but completely omits role-based or permission-based validation before returning the data.
The operational impact of this vulnerability is severe and directly affects the confidentiality and integrity of sensitive financial data within the CRM system. An authenticated user holding a low-privileged "User"/"Usuario" role can exploit this flaw to access arbitrary bank account records belonging to their company, potentially exposing critical banking information including IBAN numbers, SWIFT/BIC codes, and various account identifiers. This unauthorized disclosure represents a significant risk for organizations relying on the platform, as it could lead to financial fraud, compliance violations, and reputational damage. The vulnerability essentially allows privilege escalation within the scope of the user's company, enabling data access that should be restricted to higher-privileged roles or specific authorized personnel.
From a cybersecurity perspective, this vulnerability aligns with several ATT&CK framework techniques including T1078 Valid Accounts for initial access and T1566 Impair Defenses for maintaining persistence through compromised credentials. The flaw also demonstrates poor defense-in-depth principles where the authentication mechanism is insufficient to prevent unauthorized data access. Organizations should implement proper authorization checks using role-based access control (RBAC) or attribute-based access control (ABAC) models, ensuring that API endpoints validate not just authentication but also appropriate permissions before returning sensitive data. This requires implementing middleware or controller-level checks that verify user roles against required permissions before executing database queries and returning results to prevent unauthorized information disclosure.
Mitigation strategies should include implementing comprehensive permission validation in the API endpoint by adding proper authorization checks similar to those enforced in the web interface, modifying the controller logic to verify appropriate permissions before querying sensitive data, and ensuring consistent security enforcement across all application interfaces. The fix should involve adding explicit permission gates or role verification mechanisms that align with the existing web interface security model. Additionally, organizations should conduct comprehensive security testing including both authentication and authorization validation to identify similar inconsistencies across their applications, implement proper logging of access attempts to sensitive resources, and establish regular security audits to prevent such vulnerabilities from persisting in production environments.