CVE-2026-54601 in FastGPT
Summary
by MITRE • 07/07/2026
FastGPT is an open source AI knowledge base platform. From 4.14.17 to before 4.15.0-beta4, FastGPT allows an authenticated tenant user to call POST /api/core/dataset/collection/create/reTrainingCollection in a way that persists a server-owned datasetId value from another tenant. This creates mixed dataset objects and downstream dataset, collection, and training endpoints then make authorization decisions from inconsistent ownership anchors, allowing cross-tenant read, update, and delete access when mixed object ids are known. This issue is fixed in version 4.15.0-beta4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/08/2026
This vulnerability in FastGPT represents a critical cross-tenant data isolation failure that undermines the fundamental security model of the platform. The flaw exists in the dataset management functionality where authenticated tenant users can manipulate the dataset creation endpoint to persist dataset identifiers from other tenants within their own dataset objects. This creates a scenario where dataset objects become "mixed" with foreign datasetIds, leading to inconsistent ownership metadata that subsequent authorization checks rely upon. The vulnerability specifically affects versions between 4.14.17 and before 4.15.0-beta4, indicating a regression or incomplete fix in the authentication and authorization mechanisms.
The technical implementation of this flaw occurs through the POST /api/core/dataset/collection/create/reTrainingCollection endpoint which fails to properly validate dataset ownership context when processing tenant-specific requests. When a malicious tenant user submits a request containing a server-owned datasetId from another tenant, the system persists this foreign identifier without proper validation or sanitization. This creates a condition where downstream operations that depend on dataset ownership for authorization decisions become confused by the inconsistent data state, effectively allowing unauthorized access to resources belonging to other tenants. The vulnerability leverages the principle of least privilege violation by enabling cross-tenant data access through manipulation of internal dataset identifiers.
The operational impact of this vulnerability is severe as it enables comprehensive unauthorized access across tenant boundaries including read, update, and delete operations on sensitive dataset objects. Attackers with valid tenant credentials can exploit this flaw to gain visibility into other tenants' data, modify their datasets, and potentially disrupt service availability. The mixed dataset object scenario creates a persistent security risk where the authorization system's decision-making process becomes unreliable due to conflicting ownership anchors. This type of vulnerability directly violates the core security principle of multi-tenancy isolation and could result in data breaches, compliance violations, and significant operational damage.
This vulnerability aligns with CWE-284 (Improper Access Control) and represents a specific instance of authorization bypass through improper input validation and context handling. From an ATT&CK framework perspective, this maps to privilege escalation techniques where an authenticated user leverages system implementation flaws to gain unauthorized access to resources. The issue demonstrates poor input sanitization practices and inadequate boundary checking in multi-tenant environments, which are common attack vectors in cloud-based applications. Organizations should implement proper dataset ownership validation at all API endpoints, ensure consistent authorization context throughout request processing, and maintain robust tenant isolation mechanisms. The fix in version 4.15.0-beta4 likely addresses the root cause through improved input validation and stricter ownership verification during dataset creation operations.
The remediation approach should include comprehensive input validation for all dataset identifiers, mandatory ownership verification before persisting cross-tenant references, and implementation of proper tenant context isolation throughout the API request lifecycle. Organizations running FastGPT should urgently upgrade to version 4.15.0-beta4 or later and conduct thorough security assessments of their multi-tenant configurations. Additional defensive measures include implementing rate limiting for dataset operations, logging all cross-tenant access attempts, and establishing monitoring for unusual patterns in dataset ownership changes that could indicate exploitation attempts.