CVE-2026-77298: SeaweedFS S3 OIDC Bearer authentication bypasses IAM role trust policy
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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
SeaweedFS S3 OIDCto a version that resolves this vulnerability.Fixed in 4.40
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs a valid external OIDC JWT for a federated user and a mapping that causes the direct S3 bearer-authentication path to select an IAM role. The role's trust policy may explicitly reject that token's federated provider; that rejection is bypassed only through the direct S3 API bearer path.
What access can an attacker obtain?
The attacker is authenticated as the mapped IAM role, and SeaweedFS evaluates that role's attached S3 permissions. Depending on those permissions, this can include reading, writing, or deleting objects.
Are deployments using STS AssumeRoleWithWebIdentity affected in the same way?
The standard STS AssumeRoleWithWebIdentity path enforces the role trust policy and rejects tokens from untrusted federated providers. The bypass occurs when a raw external OIDC JWT is supplied directly in the S3 API Authorization header.
What should be done if an immediate upgrade is not possible?
The provided information identifies the direct S3 bearer-authentication path as the affected path. Restricting or disabling use of raw external OIDC JWTs directly against the S3 API would avoid that path, where operationally feasible.
Which versions contain the fix?
SeaweedFS version 4.40 fixes the issue. Versions 4.39 and earlier are affected.