CVE-2026-78365: Roskus Prospero Flow CRM Auth Bypass Flaw

CVE-2026-78365 Overview

CVE-2026-78365 is an authorization bypass vulnerability in the supplier API of Roskus Prospero Flow CRM versions 4.0.0 through 5.3.1. Any authenticated user can read and modify another company's supplier record by sending a PUT request to /api/supplier/{id}. The attacker can also reassign the supplier to their own tenant by setting company_id in the request body. The flaw is classified as an Insecure Direct Object Reference (IDOR) tracked under [CWE-639].

Critical Impact
Cross-tenant data exposure and hijacking. Any authenticated tenant can enumerate, modify, and steal supplier records belonging to other companies in a shared deployment.

Affected Products

Roskus Prospero Flow CRM 4.0.0 through 5.3.1
Deployments exposing the /api/supplier/{id} endpoint
Multi-tenant instances relying on company_id scoping

Discovery Timeline

2026-08-24 - CVE-2026-78365 published to NVD
2026-08-24 - Last updated in NVD database

Technical Details for CVE-2026-78365

Vulnerability Analysis

The SupplierUpdateController in Prospero Flow CRM accepts an object identifier from the URL and a JSON payload from the request body without validating tenant ownership. The SupplierRequest form request only checked Auth::check() before authorizing the update. This meant any authenticated session — regardless of the user's company_id — could target a supplier record belonging to another tenant.

Because the payload is mass-assigned onto the Supplier model, an attacker can supply arbitrary field values, including company_id. Setting company_id to the attacker's tenant reassigns the victim's supplier record. The result is cross-tenant read, write, and ownership transfer through a single request.

Root Cause

The root cause is missing object-level authorization combined with unrestricted mass assignment. The controller trusted user-supplied keys as authoritative and never verified that the target Supplier belonged to the authenticated user's company. The mapped weakness is [CWE-639]: Authorization Bypass Through User-Controlled Key.

Attack Vector

The attacker authenticates as any legitimate tenant user, then issues a PUT /api/supplier/{id} request against a supplier ID enumerated across the tenant boundary. Including company_id in the JSON body relocates the record to the attacker-controlled tenant. No user interaction and no elevated privileges are required.

php

// Patch: app/Http/Requests/API/SupplierRequest.php
 public function authorize(): bool
 {
-    return Auth::check();
+    $user = Auth::user();
+
+    if (! $user) {
+        return false;
+    }
+
+    if ($this->isMethod('put') || $this->isMethod('patch')) {
+        return $user->can('update supplier');
+    }
+
+    return $user->can('create supplier');
 }

Source: GitHub Commit 4a52477

Detection Methods for CVE-2026-78365

Indicators of Compromise

PUT or PATCH requests to /api/supplier/{id} where the {id} path parameter references a supplier not belonging to the authenticated user's company_id.
Request bodies to the supplier API that include a company_id field, especially when the value differs from the authenticated session's tenant.
Sudden ownership changes on Supplier records where company_id transitions between tenants without an administrative workflow.

Detection Strategies

Instrument the API layer to log the authenticated user's company_id alongside the resolved supplier's company_id and alert when they diverge.
Review Laravel application logs for anomalous 200 OK responses on supplier update endpoints originating from low-privilege accounts.
Baseline typical supplier update volume per tenant and flag statistical outliers indicative of enumeration.

Monitoring Recommendations

Enable database-level audit logging on the suppliers table, capturing writes to company_id.
Forward API access logs to a centralized analytics platform for cross-tenant correlation.
Alert on repeated 4xx-to-2xx transitions against /api/supplier/{id} that suggest ID enumeration succeeded.

How to Mitigate CVE-2026-78365

Immediate Actions Required

Upgrade Prospero Flow CRM to version 5.5.3 or later, which contains the tenant-scoped authorization fix.
Audit the suppliers table for records whose company_id was changed while running an affected version and reconcile ownership with tenant administrators.
Rotate API tokens for any accounts observed issuing suspicious supplier update requests.

Patch Information

The vendor released the fix in GitHub Release v5.5.3. The relevant code change is documented in GitHub Commit 4a52477, which introduces permission checks in SupplierRequest::authorize() and removes the direct trust in Auth::check(). Additional analysis is available in the Security Analysis of CVE-2026-78365.

Workarounds

Restrict access to the /api/supplier/{id} endpoint at a reverse proxy or WAF layer until patching is complete.
Add a middleware that rejects supplier update requests when the target supplier's company_id does not match the authenticated user's tenant.
Strip the company_id field from inbound JSON payloads to prevent mass-assignment-driven tenant hijacking.

bash

# Example nginx rule to block PUT/PATCH on the supplier API pending patching
location ~ ^/api/supplier/[0-9]+$ {
    if ($request_method ~ ^(PUT|PATCH)$) {
        return 403;
    }
    proxy_pass http://prospero_backend;
}