CVE-2026-77759 in Prospero Flow CRM
Summary
by MITRE • 08/21/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified as a Bypass of Authorization Controls represents a critical flaw within the transaction API module of Roskus Prospero Flow CRM versions 5.0.0 through 5.3.5. This security defect stems from an insecure direct object reference mechanism where the application fails to enforce proper access control policies on sensitive data resources. Specifically, the GET /api/transaction/{id} endpoint accepts a user-controlled identifier for transaction records but processes this request without validating whether the authenticated user possesses the requisite permissions to view the specific record associated with that identifier. The system resolves the requested resource solely based on the provided numeric or string ID incrementing it sequentially allows an attacker who has valid authentication credentials to systematically iterate through these identifiers, thereby accessing transaction data belonging to other companies operating on the same multi-tenant instance of the software.
From a technical perspective, this flaw is classified under CWE-284 Improper Access Control and more specifically aligns with CWE-639 Injection of Critical Data Fields if the ID manipulation leads to broader system compromise, though in this context it primarily manifests as an Insecure Direct Object Reference or IDOR which falls under CWE-602. The root cause lies in the backend logic that retrieves transaction objects using a primary key without cross-referencing against the user's organizational scope or role-based access control lists. Because the API endpoint does not implement server-side validation to ensure that the requested resource belongs to the tenant associated with the authenticated session, it effectively treats all resources as publicly accessible within the context of an authorized login. This lack of contextual authorization checking allows for horizontal privilege escalation where a user can view data belonging to peers or other organizations rather than escalating privileges vertically to gain administrative rights.
The operational impact of this vulnerability is severe due to the sensitive nature of transactional data contained within CRM systems. An authenticated attacker with minimal initial access can exfiltrate confidential business information including customer details, financial records, contract terms, and communication histories from competing or unrelated organizations sharing the same instance. This breach compromises confidentiality integrity across multiple tenants potentially violating regulatory compliance requirements such as GDPR HIPAA or PCI-DSS depending on the data types involved. Furthermore the ability to enumerate valid transaction IDs can facilitate further attacks by revealing patterns in business operations identifying high-value targets or exposing internal workflows that could be leveraged for social engineering or targeted phishing campaigns against specific organizations.
To mitigate this vulnerability, immediate remediation should focus on implementing robust authorization checks at the API level before any data retrieval occurs. Developers must ensure that every request to access a transaction record includes validation logic that verifies the authenticated user's organization ID matches the organization ID associated with the requested transaction resource. This can be achieved by modifying the backend service layer to join the transaction table with an ownership or tenant mapping table and filtering results based on the session context rather than relying solely on the provided identifier. Additionally implementing rate limiting and anomaly detection for sequential API requests can help detect automated enumeration attempts while enforcing strict input validation ensures that only expected data formats are processed. Regular security audits and penetration testing focusing on horizontal privilege escalation scenarios should be conducted to identify similar flaws in other endpoints within the application architecture ensuring comprehensive protection against IDOR vulnerabilities across all user-facing interfaces.