Prospero Flow CRM EUVD-2026-63906

The attacker must hold a valid authenticated user session on the target Prospero Flow CRM instance running versions 5.0.0-5.3.5; no elevated role is required beyond basic login. The vulnerability is most impactful on multi-tenant deployments where multiple companies share one instance - single-tenant deployments expose no cross-company data. No special feature must be enabled and no non-default configuration is required: the /api/transaction/{id} endpoint is part of the standard transaction API. Exploitation is bounded by two factors: (1) a valid user account is required (no unauthenticated exploitation despite the PR:N claim in the supplied CVSS 4.0 vector, which conflicts with the description and should be treated with caution), and (2) transaction IDs must be guessable or enumerable, which is trivial given they are sequential integers.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N) scores 8.7 and includes PR:N (no privileges required), which directly conflicts with the CVE description stating exploitation is performed by 'an authenticated user.' This discrepancy is a data quality issue that should be verified with the vendor or NVD - the realistic attack surface is bounded by requiring a valid account on the instance, meaningfully reducing exposure below what PR:N implies. Attack complexity is genuinely low once authenticated: sequential integer enumeration requires no special tooling. Impact is high for multi-tenant deployments where companies share an instance; single-tenant deployments have no cross-company data to expose, reducing practical risk to near zero for that topology. No CISA KEV listing and no confirmed POC code exist; EPSS data was not provided. Overall, real-world priority is medium-high for multi-tenant deployments, low for single-tenant.

An authenticated attacker with any valid low-privilege account on a multi-tenant Prospero Flow CRM instance sends sequential HTTP GET requests to /api/transaction/1, /api/transaction/2, and so on using a standard HTTP client or browser. Because the vulnerable code performs Transaction::find($id) with no company filter, the server returns full transaction records for every company on the instance. No special tooling, elevated privileges, or knowledge of other companies' identifiers beyond the integer range is required.