FastGPT Pre-Auth BOLA: Cross-Tenant Authorization Bypass via Dataset ID Override

Vulnerability Overview FastGPT: allows server-owned override causing cross-tenant authorization confusion Vulnerability Description: FastGPT allows an authenticated tenant user to persist a value from another tenant by calling . This results in the creation of hybrid dataset objects, such as a collection owned by Tenant B pointing to a dataset owned by Tenant A. Downstream dataset, collection, and training endpoints make authorization decisions based on inconsistent ownership anchors. Impact: Cross-tenant authorization confusion and integrity issues affect hybrid collection/data/training objects. Security Boundary: The violated boundary is the consistency of tenant/workspace ownership for dataset collections, datasets, data source files, and training rows. Prerequisites: - FastGPT deployment running an affected version: v4.14.17, v4.14.22, or v4.14.23. - Two normal tenants or users, each with separate datasets. - User B owns a normal Dataset B and Collection B. - User B knows or can provide Tenant A's to the retraining endpoint. - Subsequent read/update/delete impacts require knowledge of the hybrid collection/data/training IDs. Scope Affected Versions: v4.14.17 ~ v4.14.23 Fixed Versions: v4.15.0-beta4 Remediation Fixed Version: v4.15.0-beta4 POC Code Verification Steps 1. Create two independent tenants: - User A owns Dataset A. - User B owns Dataset B and Collection B. 2. As User B, create a Collection B containing unique markers: 3. As User B, call the retraining endpoint using B's but A's : 4. Observe the request succeeds: 5. Confirm the hybrid state is persisted: 6. As User A, request the known B-created hybrid data row: 7. As User A, call the source/training/update endpoints targeting the hybrid collection or hybrid row: - - - - - - Training detail update/delete endpoints where training rows exist Expected vs. Actual Results Expected Results: - User B should not be able to create a collection with pointing to Tenant A. - User A should not be able to read or modify rows created by User B via a hybrid . - User B's access should not be lost even if B objects are moved into Tenant A's dataset authorization boundary. Actual Results: - User B's retraining request returns HTTP 200 / code 200. - User A's authenticated session request on the hybrid B data row returns HTTP 200 / code 200 and contains the B marker. - User A's API key request on the same hybrid row also returns HTTP 200 / code 200. - User A's authenticated session request on the hybrid B collection returns HTTP 200 / code 200 and includes the source download URL for B's source files. - User A's authenticated session request on the hybrid B collection returns HTTP 200 / code 200. - User A's authenticated session request on the hybrid B data row returns HTTP 200 / code 200; subsequent reads show the row has been permanently modified with content controlled by A. - User B's for Dataset B returns content updated by A, proving persistent integrity impact. - User A's authenticated session and requests targeting the B-created hybrid objects return HTTP 200 / code 200. Version Matrix Root Cause accepts or persists server-owned values while creating retrained/derived collections. The endpoint should derive ownership fields, such as , , and , from the authenticated source collection and current tenant context. Instead, an external can become part of the persisted collection state. Downstream authorization paths rely on different ownership anchors: Some collection-level checks use the overridden collection . Existing data/source rows may still carry B ownership. Training/data endpoints may query the provided in the request or the of the hybrid collection. This creates objects that cross tenant boundaries internally and leads to inconsistent read/update/delete authorization.

Goal Reached Thanks to every supporter — we hit 100%!

FastGPT Pre-Auth BOLA: Cross-Tenant Authorization Bypass via Dataset ID Override

More from this source