OIDC JWT confusion fixed in MinIO authentication

TL;DR — A JWT algorithm confusion bug in MinIO’s OpenID Connect auth can let an attacker forge identity tokens and mint S3 credentials with arbitrary policy if they obtain the OIDC ClientSecret.

What happened

MinIO is a high-performance, S3-compatible object storage system commonly deployed as self-hosted storage for apps, CI artifacts, backups, and Kubernetes-native stacks.

CVE-2026-33322 describes a JWT algorithm confusion vulnerability in MinIO’s OpenID Connect (OIDC) authentication flow. Per the CVE record, an attacker who knows the OIDC ClientSecret can forge arbitrary identity tokens and obtain S3 credentials with any policy, including consoleAdmin.

This is scored CVSS v4.0 9.2 (Critical). JWT/OIDC confusion issues are high-impact in practice because “only needs the client secret” often maps to real-world secret exposure paths (misconfigured CI, leaked env vars, improperly shared config), and successful token forgery collapses the identity boundary for the entire object store.

Who is impacted

• Deployments using MinIO with OIDC authentication enabled.
• MinIO releases in the affected range described by the CVE.
• Highest risk environments are those where the OIDC ClientSecret is widely distributed (e.g., shared across multiple services) or stored in places with broad read access.

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "This issue has been patched in RELEASE.2026-03-17T21-25-16Z."

• Inventory where MinIO is used as a shared platform component (clusters, tenants, internal developer platforms) and identify instances with OIDC enabled.
• Treat the OIDC ClientSecret as a high-value credential: restrict access, ensure it is not logged, and avoid reusing it across environments.
• If you suspect the OIDC ClientSecret may have been exposed, rotate it and review MinIO auth/access logs for anomalous token-based access and unexpected policy grants (e.g., consoleAdmin).