Prospero Flow CRM EUVD-2026-63935

Exploitation requires an authenticated CRM session with both transaction creation and accounting creation permissions - a standard business-user permission set, not administrative access, as confirmed by the CVSS PR:L metric. The vulnerability is exclusively relevant to multi-tenant shared-instance deployments where multiple companies co-exist in the same database; a single-company self-hosted installation has no foreign-company records to access and is therefore unaffected. The attacker must enumerate or guess valid integer IDs for bank_account_id or bank_card_id values belonging to co-tenant companies; in typical Laravel/Eloquent applications that use auto-incrementing primary keys, sequential integer guessing is trivial. Limiting factors are: (1) authentication with specific dual-permission assignment is required, (2) the deployment must be a shared multi-tenant instance, and (3) disclosed information is bounded to bank account name, institution name, and card last four digits - not full account numbers or card credentials.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3, correctly reflecting that exploitation is network-accessible but requires authenticated low-privilege access and produces only limited confidentiality impact. No EPSS score was provided in the intelligence package, so exploitation probability cannot be quantitatively benchmarked. The vulnerability is absent from CISA KEV and no public exploit code has been identified, which substantially lowers realistic urgency - exploitation requires a deliberate insider or a compromised account with the specific combined transaction-and-accounting-creation permission set. The exposed data (bank name, account name, card last four digits) is sensitive but falls short of enabling direct financial fraud without additional fields such as full card numbers or account numbers. The blast radius is strictly bounded to multi-tenant shared-instance deployments; single-tenant self-hosted installations carry no cross-company risk. On balance this is a real but moderate-priority finding: the authentication and permission prerequisites make opportunistic mass exploitation unlikely, though organizations running shared CRM instances with external or semi-trusted users should treat patching as a near-term priority rather than deferring indefinitely.

A malicious employee or compromised account holder with transaction and accounting creation permissions in a shared CRM instance increments integer bank_account_id values from their own known account ID upward, submitting POST /transaction/save requests for each candidate. Because the endpoint formerly performed no company-ownership check, a valid foreign ID is accepted, persisted, and the transaction detail view subsequently renders the target company's bank account name, institution name, and card last four digits to the attacker. No public exploit code has been identified, but the attack requires only standard HTTP request manipulation with no special tooling.