CVE-2026-77298: SeaweedFS Auth Bypass Vulnerability

CVE-2026-77298 Overview

CVE-2026-77298 is an authorization bypass vulnerability in SeaweedFS, a distributed storage system for files and blobs. Versions 4.39 and earlier accept an external OpenID Connect (OIDC) JSON Web Token (JWT) directly in the S3 API Authorization header and map it to an Identity and Access Management (IAM) role without enforcing that role's trust policy. A federated user can present a raw OIDC JWT to the S3 endpoint and assume a role they would be denied through the standard Security Token Service (STS) AssumeRoleWithWebIdentity path. The mapped role's S3 permissions then apply, granting object read, write, and delete access. The issue is fixed in version 4.40. This weakness is classified as [CWE-863: Incorrect Authorization].

Critical Impact
A valid OIDC user can bypass STS trust-policy checks and obtain unauthorized read, write, and delete access to S3 objects by sending the raw JWT directly to the SeaweedFS S3 API.

Affected Products

SeaweedFS versions 4.39 and earlier
SeaweedFS S3 API component (weed/s3api)
Deployments using OIDC-federated IAM role mapping

Discovery Timeline

2026-08-26 - CVE-2026-77298 published to the National Vulnerability Database (NVD)
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-77298

Vulnerability Analysis

SeaweedFS exposes two distinct authentication paths that consume OIDC tokens. The first is the STS AssumeRoleWithWebIdentity flow, which validates the token and enforces the target role's trust policy before issuing session credentials. The second is a direct S3 bearer path in which the S3 API accepts an OIDC JWT in the Authorization header and internally maps the token to an IAM role.

The direct S3 bearer path validated only the token's signature and claims. It did not evaluate whether the role's trust policy permits the token's federated provider or subject. The S3 request handler then authenticated the caller as the mapped role and evaluated that role's attached S3 policies, effectively granting role privileges without the trust-policy gate.

The result is inconsistent authorization enforcement between two entry points that share the same identity material. Attackers who can obtain any valid OIDC token from a configured provider gain a bypass primitive against role isolation.

Root Cause

The root cause is a missing trust-policy check in the direct OIDC bearer authentication code path in weed/s3api/s3_iam_middleware.go. Role mapping alone was treated as sufficient authorization, so a role STS would refuse for a given token was still assumable through the S3 endpoint. This falls under [CWE-863: Incorrect Authorization].

Attack Vector

An authenticated federated user obtains an OIDC JWT from a provider trusted by the SeaweedFS deployment. The user submits the raw JWT in the Authorization header of an S3 API request rather than exchanging it through STS. SeaweedFS maps the token to an IAM role whose trust policy does not permit that user, then authorizes S3 operations under that role. The attacker performs GetObject, PutObject, or DeleteObject calls against buckets the role can access.

// Security patch in weed/s3api/s3_iam_middleware.go
// Enforces role trust policy on direct OIDC bearer authentication (#10302)
			return nil, s3err.ErrAccessDenied
		}

		// Same trust-policy gate as AssumeRoleWithWebIdentity: the role mapping
		// alone must not grant a role that STS would refuse for this token.
		if err := s3iam.iamManager.ValidateTrustPolicyForWebIdentity(ctx, identity.RoleArn, sessionToken, nil); err != nil {
			glog.V(3).Infof("OIDC bearer token rejected by trust policy of role %s: %v", identity.RoleArn, err)
			return nil, s3err.ErrAccessDenied
		}

		// Create claims map and populate with standard claims and attributes
		claims := make(map[string]interface{}, len(identity.Attributes)+5)

Source: SeaweedFS commit ac524e1

Detection Methods for CVE-2026-77298

Indicators of Compromise

S3 API requests carrying an Authorization: Bearer <jwt> header where the JWT is a raw OIDC token rather than an STS-issued session credential.
Successful S3 operations by principals whose OIDC subject claim (sub) does not match the target role's trust policy.
Object-level GetObject, PutObject, or DeleteObject activity attributed to roles a given federated identity should not be able to assume.

Detection Strategies

Parse weed server logs for S3 requests authenticated via direct OIDC bearer tokens and correlate the token sub and iss claims against expected role trust relationships.
Alert on S3 API activity where the authenticated role differs from any role the same OIDC subject has previously obtained through the STS AssumeRoleWithWebIdentity flow.
Compare bucket-access patterns across federated users to identify accounts that access buckets outside their normal role scope.

Monitoring Recommendations

Enable verbose IAM logging in SeaweedFS (glog verbosity 3 or higher) to capture trust-policy decisions on the OIDC bearer path.
Forward S3 API access logs and OIDC provider issuance logs to a central data lake to enable cross-source correlation between token issuance and S3 role usage.
Track baselines of role-to-user mappings and alert on new role assumptions that were not preceded by an STS call.

How to Mitigate CVE-2026-77298

Immediate Actions Required

Upgrade all SeaweedFS instances to version 4.40 or later, which enforces the trust-policy gate on direct OIDC bearer authentication.
Audit IAM role trust policies and remove overly permissive federated principals or wildcard OIDC subjects.
Rotate any long-lived OIDC client secrets and revoke session tokens issued during the vulnerable window.
Review S3 access logs since the deployment of a vulnerable version for role assumptions not preceded by an STS call.

Patch Information

The fix is in SeaweedFS 4.40, delivered in commit ac524e140a37242b2488be9dfffae918da1d4de1. The patch adds a call to ValidateTrustPolicyForWebIdentity in the S3 IAM middleware, applying the same trust-policy gate that AssumeRoleWithWebIdentity already enforced. See the GitHub Security Advisory GHSA-757h-cm9x-wprg for full advisory details.

Workarounds

Disable direct OIDC bearer authentication on the S3 API and require clients to exchange tokens through the STS AssumeRoleWithWebIdentity endpoint.
Restrict network access to the S3 API so that only trusted service identities can present bearer tokens.
Tighten IAM role trust policies to explicitly enumerate permitted OIDC subjects and issuers, reducing the blast radius if a token is misused.

bash

# Upgrade SeaweedFS to the patched release
wget https://github.com/seaweedfs/seaweedfs/releases/download/4.40/linux_amd64.tar.gz
tar -xzf linux_amd64.tar.gz
sudo systemctl stop weed
sudo install -m 0755 weed /usr/local/bin/weed
sudo systemctl start weed
weed version   # confirm 4.40 or later