CVE-2026-77780 in Prospero Flow CRM
Summary
by MITRE • 08/21/2026
Authorization Bypass Through User-Controlled Key in the transaction save endpoint in Roskus Prospero Flow CRM 4.9.1 through 5.14.0 allows a user with transaction and accounting creation permissions to disclose another company's bank account name, bank name and card last four digits via a bank_account_id or bank_card_id belonging to that company in POST /transaction/save, which is persisted and rendered without any company ownership check.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified as an Authorization Bypass Through User-Controlled Key represents a critical flaw within the transaction save endpoint of Roskus Prospero Flow CRM versions 4.9.1 through 5.14.0. This security defect stems from a fundamental failure in server-side access control logic, specifically regarding how the application validates ownership of resources associated with financial data. The core technical issue lies in the reliance on client-supplied identifiers, namely bank_account_id or bank_card_id, to retrieve and process sensitive banking information without performing any subsequent verification against the authenticated user's organizational context. In a properly secured system, when an API endpoint accepts an identifier for a resource such as a bank account, it must cross-reference that identifier with the identity of the requesting user to ensure the user has explicit permission to access or modify that specific record within their own company scope. However, in this implementation, the application trusts the input provided by the client side without validating whether the referenced asset belongs to the tenant associated with the current session credentials.
This architectural oversight allows an attacker who possesses valid authentication and sufficient permissions to create transactions and accounting entries to manipulate the bank_account_id or bank_card_id parameters within a POST request directed at the /transaction/save endpoint. By substituting these identifiers with values belonging to another company, the application retrieves the associated sensitive data without raising any errors or access denied responses. The system persists this information in the transaction record and subsequently renders it back to the user interface. Because there is no intermediate check to confirm that the bank account ID corresponds to an entity owned by the requesting user's organization, the confidentiality of proprietary financial details is compromised. This type of flaw is classically categorized under CWE-639, which describes Authorization Bypass Through User-Controlled Key, and it aligns with MITRE ATT&CK technique T1078, specifically relating to Valid Accounts used for unauthorized access to sensitive data within a multi-tenant environment.
The operational impact of this vulnerability is significant due to the sensitivity of the exposed information. An attacker can disclose another company's bank account name, bank name, and the last four digits of their card numbers. While the full card number is not revealed, the combination of these three pieces of data constitutes a high-risk exposure that can facilitate further social engineering attacks or fraud attempts against the affected organization. For financial institutions and enterprises using this CRM system, such leakage violates strict regulatory compliance requirements regarding personally identifiable information and financial data protection standards like PCI DSS and GDPR. The persistence of this data in transaction records means that once accessed, the compromised information may be stored indefinitely unless manually purged, increasing the long-term risk profile for both the victim organization and its banking partners who rely on the integrity of these shared details.
Mitigation strategies must focus on implementing robust server-side authorization checks at every point where external identifiers are used to access resources. Developers should enforce strict ownership validation by ensuring that any query retrieving bank account or card information includes a filter matching the current user's company ID against the resource's owner ID. Additionally, employing indirect reference maps rather than exposing direct database keys in API payloads can reduce the risk of such bypasses. Input validation alone is insufficient; logical access control must be enforced at the business logic layer to guarantee that users can only interact with data explicitly assigned to their organizational unit. Upgrading to a patched version of Roskus Prospero Flow CRM where this flaw has been addressed by the vendor remains the most immediate and effective remediation step for affected deployments.