Prospero Flow CRM CVE-2026-19870

Exploitation requires a valid authenticated session with at least the read payroll permission (for data disclosure) or the create payroll permission (for cross-tenant record injection). The application must be running in a multi-tenant configuration hosting more than one company; in a single-tenant deployment no cross-company data is present to leak, though over-permissioned internal users could still access all payroll data. No non-default configuration, special feature flag, or elevated administrator role beyond standard payroll permissions is necessary. Exploitation is not possible for unauthenticated users or for authenticated users who have not been granted any payroll permission. The attack does not require any user interaction from a victim.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) accurately reflects the attack profile: the endpoint is network-reachable, no special conditions or elevated privileges beyond a basic payroll permission are required, and the confidentiality and integrity impacts are high because salary figures and banking account details can be read and fraudulent payroll records can be injected across tenant boundaries. No EPSS score was provided in the available intelligence, and this CVE does not currently appear in the CISA KEV catalog, so active exploitation is unconfirmed. However, the absence of KEV listing should not reduce urgency - the exploitation path requires no special tooling, chaining, or prior knowledge beyond a valid low-privilege account, meaning even a mid-sized municipal IT team in malbork running Prospero Flow CRM for multiple client companies should treat this as urgent rather than routine. The primary limiting factor is that attackers must be authenticated with at least a payroll permission, which meaningfully reduces the exposed attack surface compared to unauthenticated flaws of equivalent complexity. The integrity impact is particularly notable: the ability to insert payroll records for foreign employees could cause financial processing errors in payroll runs that are difficult to audit after the fact.

An authenticated CRM user at Company A, holding only the standard read payroll permission, sends an HTTP GET request to the payroll listing endpoint for a given year without specifying any employee filter. Because the underlying Eloquent query lacks a company_id constraint, the JSON response includes salary amounts and banking details for employees across all companies in the instance. A separate user with create payroll permission then POSTs a payroll creation request supplying an employee user_id belonging to Company B; because validation only checks global existence of the ID, the record is created successfully and attributed to the foreign employee.