Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-54601

CVE-2026-54601: FastGPT Auth Bypass Vulnerability

CVE-2026-54601 is an authentication bypass flaw in FastGPT that enables cross-tenant access to datasets through inconsistent ownership validation. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-54601 Overview

CVE-2026-54601 is a broken access control vulnerability in FastGPT, an open source AI knowledge base platform developed by labring. The flaw exists in the POST /api/core/dataset/collection/create/reTrainingCollection endpoint. An authenticated tenant user can supply a datasetId value belonging to another tenant, and the server persists that value against a collection it does not own. This produces mixed dataset objects where downstream dataset, collection, and training endpoints derive authorization from inconsistent ownership anchors. The result is cross-tenant read, update, and delete access when the mixed object identifiers are known. The issue affects versions from 4.14.17 up to 4.15.0-beta4 and is tracked under [CWE-915].

Critical Impact

Authenticated tenants can pivot to another tenant's datasets and collections, breaking the multi-tenant isolation model of the platform.

Affected Products

  • FastGPT versions 4.14.17 through 4.15.0-beta3
  • FastGPT self-hosted and containerized deployments in this range
  • FastGPT tenants sharing a single backend instance

Discovery Timeline

  • 2026-07-07 - CVE-2026-54601 published to NVD
  • 2026-07-08 - Last updated in NVD database
  • v4.15.0-beta4 - labring releases fixed version via GitHub Release v4.15.0-beta4

Technical Details for CVE-2026-54601

Vulnerability Analysis

FastGPT models tenants as isolated owners of datasets, collections, and training data. The reTrainingCollection request body accepted both a datasetId and a collectionId. The server trusted the client-supplied datasetId and stored it against the collection record without verifying that the collection actually belonged to that dataset or tenant. Subsequent operations against the collection then resolved ownership through the attacker-controlled datasetId rather than the collection's true parent, producing inconsistent authorization decisions across endpoints. This is a classic Insecure Direct Object Reference pattern combined with mismatched ownership anchors.

Root Cause

The root cause is improper binding between collections and their owning dataset. The API schema exposed datasetId as a mutable client input on a retraining call rather than deriving it server-side from the target collectionId. Because different endpoints check authorization against different fields, an attacker who mixes IDs from two tenants creates a record that some checks treat as tenant A's and others treat as tenant B's.

Attack Vector

An attacker needs a valid low-privileged FastGPT account and knowledge of the target tenant's dataset or collection identifiers. The request is a normal authenticated HTTP POST, requires no user interaction, and can be executed remotely against any reachable FastGPT instance.

typescript
// Security patch in packages/global/openapi/core/dataset/collection/createApi.ts
// Route: POST /core/dataset/collection/create/reTrainingCollection
export const ReTrainingCollectionBodySchema = DatasetCollectionStoreDataSchema.extend({
-  datasetId: z.string().meta({ description: '数据集 ID' }),
   collectionId: z.string().meta({ description: '需要重新训练的集合 ID' })
});
export type ReTrainingCollectionBodyType = z.infer<typeof ReTrainingCollectionBodySchema>;

Source: GitHub Commit 54a53e7

The patch removes the client-supplied datasetId field entirely. The server now resolves the dataset from the collectionId, eliminating the ability to mix identifiers across tenants. An equivalent change was applied to PUT /api/core/dataset/training/updateTrainingData.

Detection Methods for CVE-2026-54601

Indicators of Compromise

  • Requests to POST /api/core/dataset/collection/create/reTrainingCollection where the datasetId in the body does not match the dataset associated with the supplied collectionId.
  • Collection records in MongoDB where the stored datasetId differs from the datasetId of the collection's historical parent.
  • Access to dataset, collection, or training endpoints originating from a tenant that does not own the referenced objects.

Detection Strategies

  • Add server-side logging that records the resolved dataset owner and the requesting tenant for every retraining call, then alert on mismatches.
  • Run a database consistency job that cross-checks collection.datasetId against the dataset's tenant boundary and flags orphaned or mismatched rows.
  • Review web server and application logs for reTrainingCollection and updateTrainingData calls made before upgrading to 4.15.0-beta4.

Monitoring Recommendations

  • Monitor HTTP 200 responses on training-related endpoints followed by read or delete operations from the same session against previously untouched dataset IDs.
  • Track counts of unique datasetId values per authenticated user; sudden increases suggest ID enumeration.
  • Alert on any API activity from low-privileged tenant accounts targeting object IDs they have not previously interacted with.

How to Mitigate CVE-2026-54601

Immediate Actions Required

  • Upgrade FastGPT to version 4.15.0-beta4 or later, which is the fixed release published by labring.
  • Audit collection and dataset records created between versions 4.14.17 and 4.15.0-beta3 for cross-tenant datasetId references.
  • Rotate any API keys or session tokens that were used to invoke the affected endpoints during the vulnerable window.
  • Restrict network exposure of FastGPT administrative APIs to trusted networks until the upgrade is complete.

Patch Information

The fix is delivered in FastGPT 4.15.0-beta4. The commit 54a53e7d4399f1dfa2913394442c3cf6de672fb3 removes the client-controlled datasetId from the reTrainingCollection and updateTrainingData request schemas, forcing the server to derive dataset ownership from the collection. Details are available in the GitHub Security Advisory GHSA-qxcq-48gr-93pj and Pull Request #7071.

Workarounds

  • Place FastGPT behind an API gateway that strips or rejects the datasetId field on the affected routes until patching is complete.
  • Temporarily disable the retraining and training-data update endpoints via reverse-proxy rules if upgrade is delayed.
  • Enforce single-tenant deployments so cross-tenant object ID collisions become impossible.
bash
# Example nginx block to reject requests with a datasetId field on the vulnerable route
location = /api/core/dataset/collection/create/reTrainingCollection {
    if ($request_body ~* "\"datasetId\"") {
        return 400;
    }
    proxy_pass http://fastgpt_upstream;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.