CVE-2026-77298: 
Wolfi vulnerability analysis and mitigation

CVE-2026-77298 is an incorrect authorization vulnerability in SeaweedFS, a distributed storage system for files and blobs, where the S3 API accepts external OIDC JWTs directly in the Authorization: Bearer header and maps them to IAM roles without enforcing the role's trust policy. This allows a federated user to assume an IAM role they are not permitted to hold, bypassing the trust-policy enforcement that the standard STS AssumeRoleWithWebIdentity path correctly applies. Affected versions are 4.39 and earlier; the issue is fixed in version 4.40. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory).

The root cause is CWE-863 (Incorrect Authorization): the S3IAMIntegration.AuthenticateJWT function in weed/s3api/s3_iam_middleware.go validated the OIDC token's signature and mapped it to a role via the configured roleMapping, but never invoked the role's trust-policy check before returning an authenticated principal. In contrast, the STS AssumeRoleWithWebIdentity path calls ValidateTrustPolicyForWebIdentity and rejects tokens whose federated provider is not trusted by the target role. An attacker with a valid OIDC JWT — even one that STS would refuse — can send it directly as Authorization: Bearer <token> to any S3 API endpoint, causing SeaweedFS to authenticate the request as the mapped role and evaluate that role's attached S3 permissions. The fix (commit ac524e1) inserts the same trust-policy validation call into the bearer authentication path before returning the principal (GitHub Advisory, Fix Commit).

A valid federated OIDC user whose token would be denied role assumption through STS can obtain the mapped role's full S3 permissions — including object read, write, and delete — by presenting the raw OIDC JWT directly to the S3 API. This can result in unauthorized access to sensitive stored data (confidentiality impact), modification or corruption of objects (integrity impact), and deletion of data (availability impact). In multi-tenant or shared storage environments, this could expose data belonging to other tenants or enable an attacker to destroy critical stored assets (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the disclosure date. The vulnerability requires a low-privilege precondition — the attacker must possess a valid OIDC JWT from a configured provider — but no additional interaction or complex conditions are needed (network-accessible, low attack complexity). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The advisory was published on August 26, 2026, assigned by GitHub (GitHub Advisory).

1. Obtain a valid OIDC JWT: Authenticate with any OIDC identity provider configured in the target SeaweedFS instance to obtain a valid JWT (e.g., via standard OAuth2/OIDC authorization flows). The token does not need to be authorized for the target role through STS.
2. Identify the target role mapping: Determine which IAM role ARN the OIDC provider's roleMapping configuration maps the attacker's token claims (e.g., group membership) to. This may be discoverable through misconfigured public endpoints or insider knowledge.
3. Send the raw JWT directly to the S3 API: Craft an HTTP request to any S3 API endpoint on the SeaweedFS instance, placing the raw OIDC JWT in the Authorization: Bearer <token> header (e.g., GET /bucket/object or PUT /bucket/object).
4. Achieve unauthorized role access: SeaweedFS validates the token signature and maps it to the configured role without checking the role's trust policy, authenticating the request as the mapped role and applying its attached S3 permissions — granting read, write, or delete access to S3 objects (GitHub Advisory, Fix Commit).

• Network: Unexpected S3 API requests (GET, PUT, DELETE on buckets/objects) using Authorization: Bearer <JWT> headers from users or IP addresses not normally associated with direct S3 bearer token usage; requests where the JWT issuer does not match the trust policy of the accessed role.
• Logs: SeaweedFS access logs showing successful S3 operations authenticated via OIDC bearer tokens for roles that the same user cannot assume via STS AssumeRoleWithWebIdentity; log entries for AuthenticateJWT succeeding for role ARNs with restrictive trust policies.
• Behavioral: Unusual data access patterns (bulk reads, writes, or deletes) by federated OIDC identities on buckets they should not have access to; S3 operations on sensitive buckets from OIDC users whose group memberships map to high-privilege roles.

Upgrade SeaweedFS to version 4.40 or later, which enforces the same role trust-policy validation (ValidateTrustPolicyForWebIdentity) on the direct OIDC bearer authentication path as the STS AssumeRoleWithWebIdentity path (Fix Commit). No official configuration-based workaround is provided; as an interim measure, administrators can restrict network access to the S3 API to trusted clients only, or disable OIDC roleMapping configurations until the upgrade is applied. Requiring all OIDC users to exchange tokens for STS-issued session tokens before accessing S3 (rather than using raw bearer tokens) would also mitigate the issue (GitHub Advisory).