CVE-2026-77759: Prospero Flow CRM Auth Bypass Vulnerability

CVE-2026-77759 Overview

CVE-2026-77759 is an authorization bypass vulnerability in the transaction API of Roskus Prospero Flow CRM versions 5.0.0 through 5.3.5. An authenticated user can read transactions belonging to other companies on the same instance by incrementing the identifier in GET /api/transaction/{id}. The endpoint resolves the requested resource without applying company scoping or any permission check. This is a classic Insecure Direct Object Reference (IDOR) issue tracked as [CWE-639]. The flaw exposes cross-tenant financial data in a multi-tenant CRM deployment.

Critical Impact

Any authenticated tenant user can enumerate and read transaction records belonging to other companies on the same instance, breaching multi-tenant data isolation.

Affected Products

• Roskus Prospero Flow CRM 5.0.0 through 5.3.5
• The TransactionReadController API endpoint GET /api/transaction/{id}
• Fixed in Roskus Prospero Flow CRM v5.5.3

Discovery Timeline

• 2026-08-21 - CVE-2026-77759 published to NVD
• 2026-08-21 - Last updated in NVD database

Technical Details for CVE-2026-77759

Vulnerability Analysis

Prospero Flow CRM is a multi-tenant CRM where each company's data must be isolated from other tenants on the same instance. The TransactionReadController API endpoint accepts a numeric transaction identifier and returns the corresponding record. The controller resolves the Transaction model directly from the supplied {id} parameter without filtering by the authenticated user's company. It also does not verify that the caller holds any accounting permission. An authenticated user can therefore iterate through transaction identifiers and read financial records belonging to unrelated tenants.

Root Cause

Two defects combine to produce the bypass. First, the controller performs no tenant scoping when loading the transaction, so ownership is never checked against the authenticated user's company. Second, no permission gate such as can('read accounting') is enforced before the record is returned. The identifier is user-controlled and sequential, which makes enumeration trivial.

Attack Vector

An attacker registers or uses any valid account on the target instance and issues authenticated GET requests to /api/transaction/{id} while incrementing {id}. Each response leaks a transaction record from whichever tenant owns that identifier. No elevated privileges, user interaction, or additional protocol interaction are required.

// Patched TransactionReadController (excerpt)
namespace App\Http\Controllers\Api\Transaction;

use App\Http\Requests\TransactionReadRequest;
use App\Models\Transaction;
use Illuminate\Http\JsonResponse;
use Illuminate\Support\Facades\Auth;
use OpenApi\Attributes as OAT;

class TransactionReadController
// ...

// New TransactionReadRequest enforces the missing permission check
<?php

declare(strict_types=1);

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Support\Facades\Auth;

class TransactionReadRequest extends FormRequest
{
    public function authorize(): bool
    {
        return Auth::user()?->can('read accounting') ?? false;
    }

    public function rules(): array
    {
        return [
            //
        ];
    }
}

Source: GitHub commit 980c35a

Detection Methods for CVE-2026-77759

Indicators of Compromise

• Sequential or high-volume GET /api/transaction/{id} requests from a single authenticated session, especially with monotonically increasing identifiers.
• API responses returning 200 OK for transactions whose owning company differs from the requester's company.
• Access log entries where a single user token retrieves transaction records across many distinct company_id values.

Detection Strategies

• Correlate the authenticated user's company_id with the company_id of every returned transaction and alert on mismatches.
• Implement rate-based detection on /api/transaction/{id} to flag ID enumeration behavior from a single principal.
• Review application logs for accounts that lack the read accounting permission but successfully hit the transaction read endpoint.

Monitoring Recommendations

• Ship web server and application access logs to a centralized analytics platform and build queries that group transaction API hits by user and target tenant.
• Alert on any authenticated session issuing more than a defined threshold of distinct /api/transaction/{id} reads within a short window.
• Track the deployed Prospero Flow CRM version across environments to ensure vulnerable releases in the 5.0.0–5.3.5 range are identified.

How to Mitigate CVE-2026-77759

Immediate Actions Required

• Upgrade Roskus Prospero Flow CRM to v5.5.3 or later, which introduces TransactionReadRequest with the read accounting permission check.
• Audit application access logs for prior enumeration of /api/transaction/{id} across tenant boundaries and notify affected companies if exposure is confirmed.
• Restrict network access to the CRM API to trusted sources while patching is scheduled.

Patch Information

The vendor fix is delivered in Roskus Prospero Flow CRM v5.5.3. Commit 980c35a adds a dedicated TransactionReadRequest form request that enforces Auth::user()?->can('read accounting') before the controller executes. Additional context is available in the Securo security advisory for CVE-2026-77759.

Workarounds

• If immediate patching is not possible, add a web application firewall rule that blocks or challenges unauthenticated and low-privilege access to /api/transaction/{id}.
• Apply a temporary middleware or reverse-proxy check that rejects transaction API requests when the caller's company_id does not match the requested record's tenant.
• Revoke API tokens for accounts that do not require accounting access until the upgrade is deployed.

# Example nginx rule to require an internal header until patched
location ~ ^/api/transaction/[0-9]+$ {
    if ($http_x_internal_auth != "trusted-value") {
        return 403;
    }
    proxy_pass http://prospero_backend;
}