CVE-2026-114519 in Prospero Flow CRM
Summary
by MITRE • 10/22/2026
Missing Authorization (CWE-862) in the user API of Roskus Prospero Flow CRM from 2.0.0 before 5.26.0 allows a user with a basic role to read the accounts of other users of its own company, including accounts with higher privileges, and, in versions from 3.5.0, to delete them, because the routes GET /api/user/{id} and DELETE /api/user/{id} in routes/api.php carry only the auth:api middleware, which checks that a JSON Web Token is valid and nothing more, and neither UserReadController::read() nor UserDeleteController::delete() checks a permission, a policy or a role before acting. Object access is scoped by company: the read path limits the query to the company of the authenticated user, and the delete path compares the company of the target account with the company of the authenticated user. The delete path skips that comparison when the company of the authenticated user is Company::DEFAULT_COMPANY, so a user with a basic role in that company can delete any account of any company of the installation. Deleting an account removes the data held on it, and the last administrative account of a company can be deleted. This gives the attacker the personal data held on the other accounts, including email address, telephone number, postal address and IBAN, and the ability to delete accounts it has no permission to administer.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Roskus Prospero Flow CRM versions prior to 5.26.0 represents a critical failure in access control mechanisms, specifically categorized under CWE-862 Missing Authorization. This flaw resides within the user API endpoints responsible for retrieving and deleting user account data. The core technical deficiency lies in the middleware configuration applied to the routes GET /api/user/{id} and DELETE /api/user/{id}. These routes are protected solely by the auth:api middleware, which validates the presence of a valid JSON Web Token but performs no subsequent verification regarding the authenticated user's role or permissions relative to the target resource. Consequently, any user possessing a basic authentication token can interact with these endpoints without undergoing proper authorization checks within the controller logic itself.
The operational impact varies depending on the specific version and company configuration. In versions from 3.5.0 onwards, the delete functionality allows for significant data destruction capabilities due to flawed scoping logic. While both read and delete operations attempt to scope access by company ID, ensuring that a user can only interact with accounts belonging to their own organization, there is a critical exception in the deletion path. When an authenticated user belongs to Company::DEFAULT_COMPANY, the system skips the comparison between the target account's company and the authenticated user's company. This logic error permits users within the default company context to delete any account across all companies hosted on the installation, effectively bypassing multi-tenant isolation boundaries.
For standard scenarios outside of the default company exception, a basic role user can still read detailed personal information associated with other accounts within their own organization. The exposed data includes sensitive personally identifiable information such as email addresses, telephone numbers, postal addresses, and financial details like IBANs. This unauthorized access constitutes a severe privacy violation and aligns with ATT&CK technique T1005 Data from Local System Retrieval, where an attacker gathers critical organizational intelligence without proper privileges. The ability to view this data can facilitate further social engineering attacks or identity theft against employees and clients within the same organization.
The deletion capability poses an even more severe risk to system integrity and availability. By deleting user accounts, attackers remove associated data permanently, leading to potential loss of business-critical information. Most critically, the vulnerability allows for the deletion of administrative accounts. If a basic role user deletes the last remaining administrative account within a company, it results in a denial of service condition where no authorized personnel can manage or access that specific tenant's instance. This aligns with ATT&CK technique T1485 Data Destruction, as the attacker intentionally destroys data to impair organizational operations. The combination of unauthorized information disclosure and destructive capability makes this vulnerability particularly dangerous for enterprise deployments relying on role-based access control to maintain security boundaries.
Mitigation requires immediate patching to version 5.26.0 or later, where these authorization checks have been corrected. In the interim, organizations should enforce strict input validation and implement additional middleware layers that verify user roles against specific resource permissions before allowing API requests to reach the controller logic. It is also advisable to review database backups for any unauthorized deletions if an attack occurred prior to patching. Furthermore, developers must ensure that all API endpoints adhere to the principle of least privilege by explicitly checking policies or roles in every action method, rather than relying solely on authentication middleware. Regular security audits focusing on object-level authorization checks are essential to prevent similar flaws from recurring in other parts of the application.