CVE-2026-78365 in Prospero Flow CRM
Summary
by MITRE • 08/24/2026
Authorization Bypass Through User-Controlled Key in the supplier API in Roskus Prospero Flow CRM 4.0.0 through 5.3.1 allows any authenticated user to read and modify another company's supplier record, and to reassign it to their own company, via a PUT request to /api/supplier/{id} setting company_id in the body.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified as an Authorization Bypass Through User-Controlled Key represents a critical flaw within the Roskus Prospero Flow CRM software versions 4.0.0 through 5.3.1, specifically affecting its supplier management API endpoint. This security defect stems from insufficient server-side validation of input parameters during state-changing operations. The application fails to verify that the company identifier provided in the request body corresponds to the authenticated user's actual organizational context or permissions. Consequently, an attacker who has successfully obtained valid credentials for any legitimate account within the system can manipulate internal logic by supplying a different organization's unique supplier record identifier and overriding the associated company_id field in the HTTP PUT request payload directed at /api/supplier/{id}. This mechanism allows the authenticated user to effectively hijack ownership of another company’s data, transferring it from their original owner to the attacker’s own corporate entity.
From a technical perspective, this flaw is classified under CWE-284 Improper Access Control and more specifically aligns with CWE-639 Authorization Bypass Through User-Controlled Key. The root cause lies in the application's reliance on client-supplied data for critical authorization decisions rather than deriving access rights from server-side session state or secure token validation. By accepting a user-controlled key that dictates resource ownership, the API endpoint violates the principle of least privilege and fails to enforce proper object-level security checks. This type of vulnerability is particularly dangerous because it does not require complex exploitation techniques; standard web request manipulation tools can easily demonstrate the impact by simply altering the JSON body parameters before sending the PUT request. The lack of integrity verification on the company_id field means that the backend processes the modification without confirming whether the requesting user has administrative rights over the target organization's data.
The operational impact of this vulnerability is severe, leading to a complete breakdown of multi-tenant isolation within the CRM platform. An attacker can read sensitive supplier information belonging to other companies by accessing records they have forcibly reassigned or potentially accessed through related queries if additional access controls are similarly flawed. More critically, the ability to modify these records allows for data tampering, where an adversary could alter contact details, financial terms, or logistical information associated with a competitor’s suppliers. Furthermore, reassigning supplier records enables malicious actors to disrupt business operations by removing critical supply chain partners from their rightful owners and inserting themselves into those relationships. This can lead to significant financial loss, reputational damage, and potential regulatory non-compliance for the affected organizations, especially if sensitive personal data of vendors or customers is exposed during this unauthorized access.
In terms of threat modeling, this vulnerability facilitates actions consistent with MITRE ATT&CK techniques such as T1078 Valid Accounts, where an attacker uses legitimate credentials to gain initial access, followed by T1530 Data from Cloud Storage Object or similar data exfiltration and modification tactics depending on the specific CRM architecture. The ability to move objects between tenants is akin to lateral movement within a multi-tenant environment, allowing the attacker to pivot their influence across different organizational boundaries without needing elevated privileges for each target entity individually. This undermines the fundamental trust model of Software as a Service platforms where data segregation is paramount.
To mitigate this vulnerability, developers must implement strict server-side authorization checks that validate the relationship between the authenticated user’s session and the resource being modified. The application should ignore any company_id provided in the request body for ownership changes unless explicitly authorized by an administrator role with cross-tenant privileges, which are rare and heavily audited. Instead, the system should derive the target organization context from the secure authentication token or session data associated with the user’s login credentials. Input validation routines must ensure that only fields intended for update are processed, while critical ownership attributes like company_id remain immutable through standard API endpoints unless explicitly permitted by high-level administrative workflows. Additionally, implementing comprehensive logging and monitoring of supplier record modifications can help detect anomalous patterns indicative of such exploitation attempts in real-time.