SeaweedFS EUVD-2026-66759

Exploitation requires the attacker to possess a valid, unexpired OIDC JWT from a federated identity provider that is configured in SeaweedFS with a role-mapping rule. The OIDC provider's role mapping must associate one of the attacker's token claims (e.g., a group membership claim) to a target IAM role - the attacker does not control which role is mapped, but any mapped role is reachable. The bypass only operates via the direct S3 API bearer token path; the STS AssumeRoleWithWebIdentity endpoint correctly enforces trust policies and is not vulnerable. The attacker must be a legitimate, authenticated user of the configured OIDC provider (PR:L confirmed by CVSS vector) - unauthenticated attackers cannot forge a valid JWT without the OIDC provider's private key. Deployments that do not use OIDC federation, that have no IAM role trust policies configured, or that rely solely on local IAM credentials are not affected by this specific bypass. The vulnerability is most impactful when role trust policies are the primary mechanism for segregating access between federated user groups.

The CVSS 4.0 score of 8.7 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H accurately reflects the threat model: the attacker requires only a valid OIDC JWT from the configured federated provider (PR:L), network access to the S3 API endpoint, and no special complexity or user interaction. All three impact dimensions are rated High because the bypass grants the full permission set of the assumed IAM role, which may include unrestricted read, write, and delete access to all S3 objects. No EPSS score was provided, and this CVE is not listed in the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. The practical risk is highest for organizations that have adopted SeaweedFS with OIDC federation and have designed role trust policies to enforce access boundaries between federated users - precisely the environments where those boundaries silently fail. Deployments using only local IAM credentials or no OIDC integration are unaffected. The absence of KEV listing and public PoC moderates urgency somewhat, but the low exploitation complexity and high impact warrant prompt patching for any affected deployment.

A federated user authenticated with a configured OIDC provider obtains their valid JWT, which SeaweedFS role-mapping rules link to a privileged IAM role via a group claim. Although that role's trust policy names a different federated provider and would cause the STS endpoint to reject an AssumeRoleWithWebIdentity call, the attacker presents the raw JWT directly in the S3 API Authorization header. The S3 bearer path validates the JWT signature and applies the role mapping without checking the trust policy, authenticating the attacker as the privileged role and granting full S3 access including read, write, and delete on any objects within that role's permission scope. No public exploit code has been identified at time of analysis, though the mechanism is straightforward for any user with a valid OIDC token.