Executive brief
SeaweedFS is a distributed storage system used to store files and blobs across multiple servers. In versions 4.39 and earlier, the S3 API can be tricked into granting access to users who should not have it by accepting OIDC authentication tokens directly without checking role permissions. An attacker with a valid OIDC token can bypass security restrictions and gain unauthorized read, write, and delete access to stored objects.
Technical details
This is an incorrect authorization vulnerability (CWE-863) in SeaweedFS's S3 API OIDC Bearer token authentication. The S3 API accepts external OIDC JWTs sent in the Authorization: Bearer header and maps them to IAM roles via roleMapping, but fails to enforce the target role's trust policy before issuing the authenticated principal. In contrast, the standard STS AssumeRoleWithWebIdentity path correctly rejects such tokens when the role's trust policy does not trust the OIDC provider. An attacker with a valid OIDC token can bypass the role trust-policy check by presenting the raw JWT directly to the S3 API, causing the system to authenticate as a role they are not permitted to assume and allowing them to execute the role's attached S3 permissions (object read, write, delete). The vulnerability requires a valid OIDC token and network access to the S3 API endpoint. The fix, released in version 4.40, enforces the same trust-policy validation on the S3 bearer path that is used by AssumeRoleWithWebIdentity.
Affected products
- SeaweedFS SeaweedFS 4.39 and earlier
Timeline
- 2026-08-21: disclosed
- 2026-07-10: patched: Fix committed to master branch (version 4.40)