GPU VulnDB

Database/Control plane, storage & DevOps

SeaweedFS S3 API: raw OIDC JWT bypasses IAM role trust policy and grants that role's bucket access

CVE-2026-77298Control plane, storage & DevOpscurated

Impact

SeaweedFS is commonly used as the object store behind dataset and checkpoint buckets on GPU fleets. Its S3 endpoint accepts an external OIDC JWT presented directly in the Authorization header and maps it to an IAM role without checking that role's trust policy, so any holder of a valid token from a federated provider can act as a role they were never permitted to assume. The STS AssumeRoleWithWebIdentity path enforces the trust policy correctly, so an operator reading only the STS configuration would believe access is constrained. The practical result is read, write and delete on whatever buckets the mapped role can touch, which on a shared cluster means one tenant's OIDC identity reaching another tenant's training data, model artifacts or checkpoints.

Who can reach it

Any user who can obtain a valid OIDC token from a provider the deployment accepts and reach the SeaweedFS S3 endpoint. Authentication is required, but only as an ordinary federated user - no possession of the target role's credentials is needed.

What to do

Upgrade SeaweedFS to 4.40, which contains the fix (commit ac524e1). This is a service upgrade and restart of the S3 gateway/filer processes rather than anything touching GPU nodes; workloads holding open S3 sessions will see them break during the restart. Until the upgrade lands, restrict which OIDC issuers the S3 endpoint accepts and review role-to-bucket mappings for any role reachable by a broader identity pool than intended.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.