CVE-2026-77298 in SeaweedFS
Summary
by MITRE • 08/27/2026
SeaweedFS is a distributed storage system for files and blobs. In versions 4.39 and earlier, the S3 API accepts an external OIDC JWT sent directly in the Authorization header and maps it to an IAM role without enforcing that role's trust policy, so a federated user can assume a role they are not permitted to hold. The standard STS AssumeRoleWithWebIdentity path rejects such a token when the role's trust policy does not trust the token's federated provider, but the direct S3 bearer path validates only the token itself and then authenticates as the mapped role and evaluates that role's attached S3 permissions. As a result, a valid OIDC user whose token would be denied the role through STS can obtain the role's S3 access, including object read, write, and delete, by presenting the raw OIDC JWT directly to the S3 API. This issue is fixed in version 4.40
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/27/2026
SeaweedFS versions prior to 4.40 contain a critical authentication bypass vulnerability within its S3-compatible API implementation that allows federated users to assume IAM roles without proper trust policy enforcement. The system utilizes OpenID Connect (OIDC) for identity federation, where external JSON Web Tokens are presented by clients to authenticate against the storage service. In this flawed configuration, when an OIDC JWT is submitted directly in the Authorization header of an S3 API request, SeaweedFS maps the token's claims to a specific IAM role and proceeds to evaluate only that role’s attached bucket policies for authorization decisions. This direct path bypasses the standard Security Token Service (STS) AssumeRoleWithWebIdentity workflow, which correctly validates whether the federated identity provider is explicitly trusted by the target role’s trust policy before allowing the assumption of privileges.
The technical root cause lies in the inconsistent validation logic between two distinct authentication entry points within the SeaweedFS architecture. The STS endpoint strictly enforces IAM trust policies, ensuring that a federated user can only assume roles where the identity provider is listed as an allowed principal. However, the direct S3 API handler skips this critical verification step. It accepts any validly signed OIDC token and immediately maps it to a role based on static configuration or claim mapping rules, ignoring whether the specific identity source has been granted permission to act on behalf of that role by the trust policy administrator. This architectural inconsistency creates a significant gap in access control where an attacker possessing a valid JWT from a non-trusted provider can bypass administrative restrictions designed to limit privilege escalation paths.
The operational impact of this vulnerability is severe, as it effectively nullifies the principle of least privilege for federated identities interacting with SeaweedFS via S3 APIs. An authenticated user who would normally be denied access due to restrictive trust policies can now obtain full control over any bucket associated with the mapped role. This includes unrestricted read, write, and delete operations on stored objects. In a production environment, this could lead to data exfiltration, unauthorized modification of critical files, or complete destruction of storage assets depending on the permissions attached to the exploited IAM role. The vulnerability is particularly dangerous because it exploits standard OIDC flows that are commonly used in cloud-native applications, making it difficult for defenders to distinguish between legitimate federated access and malicious exploitation without deep inspection of trust policy configurations.
This flaw aligns with CWE-287 Improper Authentication, specifically the failure to verify identity claims against expected trust relationships during role assumption. It also maps directly to MITRE ATT&CK technique T1098.004 Account Manipulation: Additional Cloud Roles, where an adversary manipulates or exploits IAM configurations to gain unauthorized access to cloud resources by assuming roles they are not explicitly permitted to hold. To mitigate this risk, organizations must upgrade SeaweedFS to version 4.40 or later, which corrects the authentication logic in the S3 API handler to enforce trust policy validation consistent with the STS implementation. Additionally, administrators should audit existing IAM role configurations and ensure that only necessary identity providers are granted permission to assume roles, minimizing the blast radius if similar vulnerabilities exist in other components of the infrastructure.