FastGPT Flaw (CVE-2026-55418) Exposes Cross-Team Files via S3 Key Manipulation

A newly disclosed vulnerability in FastGPT, the popular open-source AI application platform from Labring, allowed attackers to access chat files and dataset documents belonging to completely unrelated organizations in one case, without even logging in.

Tracked as CVE-2026-55418 and rated High severity (CVSS 3.1 score: 7.5), the flaw stemmed from a classic but often-overlooked mistake: trusting a file identifier without verifying who actually owns it.

FastGPT Flaw (CVE-2026-55418)

Security researcher geo-chen reported the issue, and FastGPT maintainer c121914yu published the advisory (GHSA-6rxv-p43w-mmx5) last week, shipping a fix in version v4.15.0-beta5. All earlier versions remain exposed.

FastGPT stores uploaded files in S3-compatible buckets using predictable key structures; chat files follow the patternchat/<appId>/<uId>/<chatId>/<filename>, while dataset files use dataset/<datasetId>/<filename>. Critically, these keys are global across the entire bucket. The only thing separating one tenant’s files from another’s is a path segment, not an actual access control boundary.

Two handlers failed to enforce that boundary. Instead of checking whether a requested file key belonged to the caller’s team, they checked whether the caller had access to some other, unrelated resource then signed or fetched whatever key was submitted anyway.

The presignChatFileGetUrl endpoint calls authChatCrud, which validates that the caller can access a given appId including via a public share link, with no chat ID required. Once that check passes, the endpoint signs a download URL for whatever key value the request contains, without ever inspecting it.

This means an attacker holding a public share link to any single FastGPT app could submit another team’s chat-file key and receive a valid, working download URL for that stranger’s uploaded file: no account, no credentials, no interaction beyond crafting a request.

The getPreviewChunks endpoint has a similar logic error. It authorizes the attacker’s own dataset (checking they have write access) while separately validating the victim’s file through authCollectionFile a function that, per the advisory, “returns new Permission({ role: ReadRoleVal, isOwner: true }) unconditionally” once it confirms the S3 object merely exists, regardless of who owns it.

Any authenticated user with write access to a single dataset they control could submit another team’s dataset file key and receive parsed raw text and chunks from that victim file.

“This bug is a textbook reminder that authorization isn’t transitive proving someone owns Resource A tells you nothing about whether they own Resource B. The fix FastGPT already had, in its image-preview handler, took three lines: derive the tenant ID, then filter the key against it. Every team building on S3-style storage should be asking whether that same three-line check exists on every signing path, not just the ones someone remembered to secure.”

The advisory classifies this under CWE-639: Authorization Bypass Through User-Controlled Key a well-documented pattern where systems fail to validate that a caller-supplied identifier actually belongs to that caller.

The researcher notably found the correct pattern already implemented elsewhere in FastGPT’s codebase (getSearchTestImagePreviewUrls.ts), which properly filters keys against teamId before signing. The vulnerable handlers simply never inherited that safeguard.

Mitigation

FastGPT’s patch, per the advisory, binds object keys to authorized tenants before any signing or reading occurs, validating that chat keys match the caller’s appId and uId, and that dataset file lookups verify true team ownership rather than object existence alone.

Organizations running self-hosted FastGPT instances below v4.15.0-beta5 should upgrade immediately, particularly if chat sharing or multi-tenant dataset features are in use, given the confidentiality impact and zero authentication requirement on the chat-file vector.