CVE-2026-55873: Improper Authorization in SeaweedFS S3Tables and Iceberg REST Management APIs

SeaweedFS is a distributed object storage and file system optimized to manage massive volumes of small files. To expand structured storage functionality, the architecture supports S3Tables and Iceberg REST Catalog management interfaces. These components expose specialized APIs that let applications manage database-like structures directly through object storage endpoints.\n\nThis implementation introduces a target-rich attack surface because client services interact with structural catalogs via standard S3 API credentials. Authorization is governed by Amazon Signature Version 4 (SigV4) parameters, which are processed by a core policy enforcement engine designed to maintain logical namespace separation between distinct accounts.\n\nIn SeaweedFS versions 4.08 through 4.33, three distinct logic flaws within this policy engine lead to improper authorization (CWE-863). Authenticated, low-privileged users can bypass directory isolation constraints, enabling unauthorized lookup of administrative table buckets and metadata. This exposure subverts the isolation required in multi-tenant environments.

The primary vulnerability resides within the identity resolution engine of the S3Tables API. When processing a SigV4 signed request, the S3Tables API handler extracts the user context to determine the requester's account ID. If the request originates from a static IAM user that does not contain a structured account configuration block, the resolver collapses this identity to the shared administrative principal ID (s3_constants.AccountAdminId). This collapse causes downstream authorization routines to treat the standard user as the cluster administrator.\n\nThe second root cause involves the zero-configuration fallback mechanism. To facilitate ease of deployment, the platform implements a default-allow state (defaultAllow) that permits API operations if no explicit policy denies them. In vulnerable versions, this setting is mistakenly applied to authenticated sessions, meaning any successfully authenticated identity falls open to having all actions allowed unless an explicit denying policy exists in the user profile.\n\nLastly, the security gate inside the table bucket listing API (ListTableBuckets) relies on a self-referential check. The code compares the requesting principal directly against the designated owner ID variable. Because both parameters are initialized from the same requester identity, the permission check evaluates to a tautology that always resolves to true. As a result, the top-level authorization barrier is completely bypassed, allowing users to enumerate resources regardless of actual ownership.

The identity resolution logic resides in weed/s3api/s3tables/handler.go. Under the vulnerable implementation, the getAccountID function resolves the account mapping using the following logic:\n\ngo\n// Vulnerable Implementation (getAccountID)\nfunc (h *S3TablesHandler) getAccountID(r *http.Request) string {\n // ... extraction logic ...\n idField := accountVal.FieldByName(\"Id\")\n if idField.IsValid() && idField.Kind() == reflect.String {\n if principal := normalizePrincipalID(idField.String()); principal != \"\" {\n return principal // Returns \"admin\" (AccountAdminId) for any account-less user\n }\n }\n // ...\n}\n\n\nBecause any account-less caller returns the administrative principal, the policy engine evaluates actions against the administrative privilege set. The patch in commit b13463880c1fa62e255c058a9228b63cc95b4b36 resolves this by verifying if the caller possesses genuine administrative capabilities before assigning the admin ID:\n\ngo\n// Patched Implementation (getAccountID)\nif principal := normalizePrincipalID(idField.String()); principal != \"\" {\n // Account-less identities default to the admin account; only\n // keep it for real admins, else use the unique identity name.\n if principal != s3_constants.AccountAdminId || hasAdminAction(getIdentityActions(r)) {\n return principal\n }\n}\n\n\nAdditionally, the list handler in weed/s3api/s3tables/handler_bucket_get_list_delete.go previously verified list actions using a tautological check where principal and accountID were identical. This top-level check has been removed in the patched release. Permissions are now validated dynamically inside the iteration loop, querying the exact metadata of each target resource to perform granular, per-bucket access verification.

Exploiting CVE-2026-55873 requires only basic, authenticated S3 access keys valid for the target SeaweedFS deployment. The attack is executed over the network using standard S3 client tools or direct HTTP clients. No specialized exploits or complex conditions are required to execute this bypass.\n\nAn attacker signs an S3Tables API request (such as a request to the ListTableBuckets endpoint) with the service name parameter set to s3tables. Because the identity resolution logic collapses the account-less user to the administrative context, the backend processing engines fail to apply the isolation barriers intended for the low-privileged credential set.\n\nOnce the request reaches the ListTableBuckets route, the self-referential authorization gate evaluates to true. The system processes the bucket list loop, applying the open fallback parameter. The server then responds with a complete payload of all available table buckets in the storage cluster, exposing administrative names, ARNs, and structural settings.

The CVSS v3.1 score for this vulnerability is 4.3 (Medium), reflecting a CVSS vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. The attack complexity is low, requiring only standard, low-privileged network access to the API endpoints of the target cluster.\n\nThe primary consequence is unauthorized metadata exposure. An attacker can map out the entire organizational architecture of the data lake by enumerating table bucket definitions, table structures, and ARNs. In multi-tenant environments, this bypass represents a compromise of logical data isolation boundaries.\n\nWhile direct data manipulation or system compromise is restricted under standard exploitation paths, exposure of the Iceberg REST Catalog could lead to schema modifications or unauthorized namespace registration in deployments where the authentication middleware is misconfigured. This metadata collection serves as a significant reconnaissance step for further targeted attacks against the stored datasets.

To remediate this issue completely, administrators must upgrade SeaweedFS to version 4.34 or higher. The updated version removes the self-referential authorization gates and restricts the fallback options to ensure that authenticated requests fail closed unless an explicit policy grants permission.\n\nIf an immediate upgrade is not possible, access to S3Tables and Iceberg REST interfaces should be restricted using network-level security controls. Firewalls or security groups should block external traffic to the catalog ports, limiting access only to trusted workloads and system components.\n\nFurthermore, administrators should audit static S3 identities to ensure that each credential set is mapped to an explicit, non-administrative account block. Writing explicit "Deny" statements in bucket policies for low-privileged accounts will override any default-allow fallback logic in the authorization engine, mitigating the vulnerability until the software can be patched.