CVE-2026-72921

A vulnerability in SeaweedFS versions 4.08 through 4.33 allows an authenticated low-privileged S3 user to enumerate administrator-owned table bucket names and ARNs. The issue stems from incorrect routing of SigV4 requests to the S3Tables management API, where authorization collapses account-less S3 identities into the shared admin account.

SeaweedFS before 4.24 has a vulnerability in the FetchAndWriteNeedle RPC that lacks authentication and target validation. An attacker can send requests to arbitrary hosts, including cloud metadata endpoints, and read the responses.

SeaweedFS before 4.24 registers the SeaweedIdentityAccessManagement gRPC service without mandatory authentication when jwt.filer_signing.key is unset. Any client with gRPC access can create users and access keys, gaining S3 administrative control.

SeaweedFS before version 4.30 has a vulnerability due to improper path cleaning in S3 and Iceberg REST catalog routers. An attacker can use '..' sequences in a request to bypass access controls and read or write data in any bucket.

SeaweedFS is a distributed storage system for files and blobs. In versions prior to 4.40, an authenticated S3 principal with permissions scoped to a nested object key can overwrite a different object outside that scope by calling PutObjectAcl on the key it is allowed to access. The handler authorizes the request against the requested nested key but then writes the updated entry back to the bucket root rather than the key's actual parent directory, so an ACL change on allowed/protected.txt is instead applied to protected.txt at the bucket root. Because the update carries the full entry rather than only ACL metadata, an existing target object is overwritten with the content, metadata, owner information, and ACL of the scoped object, bypassing the object-level action scoping configured through the static S3 identity file. This issue is fixed in version 4.40.

SeaweedFS is a distributed storage system for files and blobs. In version 4.39, the filer's TUS resumable-upload handler checks JWT allowed_prefixes scoping only when a session is created, letting a low-privilege tenant hijack another tenant's upload session to write content to filer paths their own token forbids. The HEAD, PATCH, and DELETE verbs that act on an existing session by its id never verify that the session's stored target path falls within the caller's allowed prefixes, so a tenant who obtains another upload's session identifier can PATCH attacker bytes into it and, on completion, have the file land at the victim's out-of-scope path. The same token can also DELETE other tenants' sessions and HEAD them to read upload progress and size, defeating the JWT prefix isolation. This vulnerability only affects deployments that configure filer JWT signing and have TUS uploads enabled. This issue is fixed in version 4.40.

SeaweedFS versions 3.88 through 4.39 have a vulnerability in the SFTP server where path permissions are checked via literal string-prefix comparison, without requiring a path-component boundary. A user with access to /tenants/alice also gets access to /tenants/alice-archive, /tenants/alice2, etc. A low-privileged SFTP user can cross ACL boundaries and read or overwrite other tenants' files.

SeaweedFS versions up to 4.39 accept an external OIDC JWT in the Authorization header and map it to an IAM role without enforcing the role's trust policy. A federated user can assume a role they are not permitted to hold, gaining S3 access (read, write, delete) by presenting the raw JWT directly to the S3 API.

SeaweedFS before version 4.34 does not reject dot-dot path segments in the X-Amz-Copy-Source header used by CopyObject and UploadPartCopy. This allows an authenticated user with access to one bucket to read objects from other buckets through server-side copy.

SeaweedFS before version 4.34 has a path traversal vulnerability in the S3 gateway DeleteMultipleObjectsHandler. An authenticated S3 principal with write access to a single bucket can delete arbitrary objects in other tenants' buckets by supplying object keys with ../ sequences in the DeleteObjects XML request body.