MinIO versions before RELEASE.2020-04-23T00-58-49Z have an authentication bypass issue in the MinIO admin API. Given an admin access key, it is possible to perform admin API operations i.e. creating new service accounts for existing access keys - without knowing the admin secret key. This has been fixed and released in version RELEASE.2020-04-23T00-58-49Z.

Impact What kind of vulnerability is it? Who is impacted?

A JWT algorithm confusion vulnerability in MinIO's OpenID Connect authentication allows an attacker who knows the OIDC ClientSecret to forge arbitrary identity tokens and obtain S3 credentials with any policy, including consoleAdmin.

An attacker with knowledge of the OIDC ClientSecret can:

- Impersonate any user identity - Obtain S3 credentials with any IAM policy, including consoleAdmin - Access, modify, or delete any data in the MinIO deployment

The attack is deterministic (100% success rate, no race conditions).

Attack Prerequisites

The attacker must know the OIDC ClientSecret. While this is a shared credential (not a private key), it is more accessible than commonly assumed:

- CVE-2023-28432 previously leaked environment variables including MINIOIDENTITYOPENIDCLIENTSECRET - Client secrets are often present in frontend OAuth configurations, mobile app bundles, CI/CD pipelines, and shared configuration files - In many organizations, the client secret is accessible to operators and engineers who should not be able to forge arbitrary identities

Affected Versions

All MinIO releases from RELEASE.2022-11-08T05-27-07Z through the final release of the minio/minio open-source project.

Patches

Fixed in: MinIO AIStor RELEASE.2026-03-17T21-25-16Z

Downloads

Binary Downloads

| Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | minio | | Linux | arm64 | minio | | macOS | arm64 | minio | | macOS | amd64 | minio | | Windows | amd64 | minio.exe |

FIPS Binaries

| Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | minio.fips | | Linux | arm64 | minio.fips |

Package Downloads

| Format | Architecture | Download | | ------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | DEB | amd64 | minio20260317212516.0.0amd64.deb | | DEB | arm64 | minio20260317212516.0.0arm64.deb | | RPM | amd64 | minio-20260317212516.0.0-1.x8664.rpm | | RPM | arm64 | minio-20260317212516.0.0-1.aarch64.rpm |

Container Images

bash Standard docker pull quay.io/minio/aistor/minio:RELEASE.2026-03-17T21-25-16Z podman pull quay.io/minio/aistor/minio:RELEASE.2026-03-17T21-25-16Z

FIPS docker pull quay.io/minio/aistor/minio:RELEASE.2026-03-17T21-25-16Z.fips podman pull quay.io/minio/aistor/minio:RELEASE.2026-03-17T21-25-16Z.fips

Homebrew (macOS)

bash brew install minio/aistor/minio

Workarounds

- Users of the open-source minio/minio project should upgrade to MinIO AIStor RELEASE.2026-03-17T21-25-16Z or later. - As a workaround, ensure that the OIDC ClientSecret is treated as a highly sensitive credential and is not exposed to untrusted parties.

Impact What kind of vulnerability is it? Who is impacted?

MinIO AIStor's STS (Security Token Service) AssumeRoleWithLDAPIdentity endpoint is vulnerable to LDAP credential brute-forcing due to two combined weaknesses: (1) distinguishable error responses that enable username enumeration, and (2) absence of rate limiting on authentication attempts. An unauthenticated network attacker can enumerate valid LDAP usernames and then perform unlimited password guessing to obtain temporary AWS-style STS credentials, gaining access to the victim's S3 buckets and objects.

All deployments with LDAP configured running an affected version are impacted.

There are two vulnerabilities:

1. User Enumeration via Distinguishable Error Messages (CWE-204) 2. Missing Rate Limiting on STS Authentication Endpoints (CWE-307)

When exploited together, an attacker can:

1. Enumerate valid LDAP usernames by observing error message differences. 3. Perform high-speed password brute-force attacks against confirmed valid users. 4. Upon finding valid credentials, obtain temporary AWS-style STS credentials (AccessKeyId, SecretAccessKey, SessionToken) with full access to the victim user's S3 resources.

Affected Versions

All MinIO releases through the final release of the minio/minio open-source project.

Patches

Fixed in: MinIO AIStor RELEASE.2026-03-17T21-25-16Z

Binary Downloads

| Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | minio | | Linux | arm64 | minio | | macOS | arm64 | minio | | macOS | amd64 | minio | | Windows | amd64 | minio.exe |

FIPS Binaries

| Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | minio.fips | | Linux | arm64 | minio.fips |

Package Downloads

| Format | Architecture | Download | | ------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | DEB | amd64 | minio20260317212516.0.0amd64.deb | | DEB | arm64 | minio20260317212516.0.0arm64.deb | | RPM | amd64 | minio-20260317212516.0.0-1.x8664.rpm | | RPM | arm64 | minio-20260317212516.0.0-1.aarch64.rpm |

Container Images

bash Standard docker pull quay.io/minio/aistor/minio:RELEASE.2026-03-17T21-25-16Z podman pull quay.io/minio/aistor/minio:RELEASE.2026-03-17T21-25-16Z

FIPS docker pull quay.io/minio/aistor/minio:RELEASE.2026-03-17T21-25-16Z.fips podman pull quay.io/minio/aistor/minio:RELEASE.2026-03-17T21-25-16Z.fips

Homebrew (macOS)

bash brew install minio/aistor/minio

Workarounds

- Users of the open-source minio/minio project should upgrade to MinIO AIStor RELEASE.2026-03-17T21-25-16Z or later.

If upgrading is not immediately possible:

- Network-level rate limiting: Use a reverse proxy (e.g., nginx, HAProxy) or WAF to rate-limit requests to the /?Action=AssumeRoleWithLDAPIdentity endpoint. - Firewall restrictions: Restrict access to the STS endpoint to trusted networks/IP ranges only. - LDAP account lockout: Configure account lockout policies on the LDAP server itself (e.g., Active Directory lockout threshold). Note: this protects against brute-force but not enumeration, and may cause denial-of-service for legitimate users.

MinIO is a High Performance Object Storage released under GNU Affero General Public License v3.0. A security issue was found where an non-admin user is able to create service accounts for root or other admin users and then is able to assume their access policies via the generated credentials. This in turn allows the user to escalate privilege to that of the root user. This vulnerability has been resolved in pull request #14729 and is included in RELEASE.2022-04-12T06-55-35Z. Users unable to upgrade may workaround this issue by explicitly adding a admin:CreateServiceAccount deny policy, however, this, in turn, denies the user the ability to create their own service accounts as well.

Summary When someone creates an access key, it inherits the permissions of the parent key. Not only for s3: actions, but also admin: actions. Which means unless somewhere above in the access-key hierarchy, the admin rights are denied, access keys will be able to simply override their own s3 permissions to something more permissive.

Credit to @xSke for sort of accidentally discovering this. I only understood the implications.

Details / PoC We spun up the latest version of minio in a docker container and signed in to the admin UI using the minio root user. We created two buckets, public and private and created an access key called mycat and attached the following policy to only allow access to the bucket called public.

json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:" ], "Resource": [ "arn:aws:s3:::public", "arn:aws:s3:::public/" ] } ] } We then set an alias in mc: mcli alias set vuln http://localhost:9001 mycat mycatiscute

And checked whether policy works: A ~/c/minio-vuln mcli ls vuln [0001-01-01 00:53:28 LMT] 0B public/ Looks good, we believe this is how 99% of users will work with access policies.

If I now create a file full-access-policy.json: json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:" ], "Resource": [ "arn:aws:s3:::" ] } ] } And then:

sh A ~/c/minio-vuln mcli admin user svcacct edit --policy full-access-policy.json vuln mycat Edited service account mycat successfully. mycat has escalated its privileges to get access to the entire deployment: sh A ~/c/minio-vuln mcli ls vuln [0001-01-01 00:53:28 LMT] 0B private/ [0001-01-01 00:53:28 LMT] 0B public/

Impact A trivial privilege escalation unless the operator fully understands that they need to explicitly deny admin actions on access keys.

Patched

commit 0ae4915a9391ef4b3ec80f5fcdcf24ee6884e776 (HEAD -> master, origin/master) Author: Aditya Manthramurthy <donatello@users.noreply.github.com> Date: Wed Jan 31 10:56:45 2024 -0800

fix: permission checks for editing access keys (#18928) With this change, only a user with UpdateServiceAccountAdminAction permission is able to edit access keys. We would like to let a user edit their own access keys, however the feature needs to be re-designed for better security and integration with external systems like AD/LDAP and OpenID. This change prevents privilege escalation via service accounts.

Impact An attacker can use crafted requests to bypass metadata bucket name checking and put an object into any bucket while processing PostPolicyBucket. To carry out this attack, the attacker requires credentials with arn:aws:s3::: permission, as well as enabled Console API access.

Patches commit 67f4ba154a27a1b06e48bfabda38355a010dfca5 Author: Aditya Manthramurthy <donatello@users.noreply.github.com> Date: Sun Mar 19 21:15:20 2023 -0700

fix: post policy request security bypass (#16849)

Workarounds Browser API access must be enabled turning off MINIOBROWSER=off allows for this workaround.

References The vulnerable code: go // minio/cmd/generic-handlers.go func setRequestValidityHandler(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r http.Request) { // ... // For all other requests reject access to reserved buckets bucketName, := request2BucketObjectName(r) if isMinioReservedBucket(bucketName) || isMinioMetaBucket(bucketName) { if !guessIsRPCReq(r) && !guessIsBrowserReq(r) && !guessIsHealthCheckReq(r) && !guessIsMetricsReq(r) && !isAdminReq(r) && !isKMSReq(r) { if ok { tc.FuncName = "handler.ValidRequest" tc.ResponseRecorder.LogErrBody = true } writeErrorResponse(r.Context(), w, errorCodes.ToAPIErr(ErrAllAccessDisabled), r.URL) return } } // ...

Impact All users on Windows are impacted. MinIO fails to filter the \ character, which allows for arbitrary object placement across buckets. As a result, a user with low privileges, such as an access key, service account, or STS credential, which only has permission to PutObject in a specific bucket, can create an admin user.

Patches There are two patches that fix this problem comprehensively

commit b3c54ec81e0a06392abfb3a1ffcdc80c6fbf6ebc Author: Harshavardhana <harsha@minio.io> Date: Mon Mar 20 13:16:00 2023 -0700

reject object names with '\' on windows (#16856)

commit 8d6558b23649f613414c8527b58973fbdfa4d1b8 Author: Harshavardhana <harsha@minio.io> Date: Mon Mar 20 00:35:25 2023 -0700

fix: convert '\' to '/' on windows (#16852)

Workarounds There are no known workarounds

References The vulnerable code: go // minio/cmd/generic-handlers.go // Check if the incoming path has bad path components, // such as ".." and "." // SlashSeparator -> / // dotdotComponent -> .. // dotComponent -> . func hasBadPathComponent(path string) bool { path = strings.TrimSpace(path) for , p := range strings.Split(path, SlashSeparator) { switch strings.TrimSpace(p) { case dotdotComponent: return true case dotComponent: return true } } return false }

MinIO is a high-performance object storage system. Starting in RELEASE.2023-05-18T00-05-36Z and prior to RELEASE.2026-04-11T03-20-12Z, an authentication bypass vulnerability in MinIO's STREAMING-UNSIGNED-PAYLOAD-TRAILER code path allows any user who knows a valid access key to write arbitrary objects to any bucket without knowing the secret key or providing a valid cryptographic signature. Any MinIO deployment is impacted. The attack requires only a valid access key (the well-known default minioadmin, or any key with WRITE permission on a bucket) and a target bucket name. PutObjectHandler and PutObjectPartHandler call newUnsignedV4ChunkedReader with a signature verification gate based solely on the presence of the Authorization header. Meanwhile, isPutActionAllowed extracts credentials from either the Authorization header or the X-Amz-Credential query parameter, and trusts whichever it finds. An attacker omits the Authorization header and supplies credentials exclusively via the query string. The signature gate evaluates to false, doesSignatureMatch is never called, and the request proceeds with the permissions of the impersonated access key. This affects PutObjectHandler (standard and tables/warehouse bucket paths) and PutObjectPartHandler (multipart uploads). Users of the open-source minio/minio project should upgrade to MinIO AIStor RELEASE.2026-04-11T03-20-12Z or later. If upgrading is not immediately possible, block unsigned-trailer requests at the load balancer. Reject any request containing X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER at the reverse proxy or WAF layer. Clients can use STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER (the signed variant) instead. Alternatively, restrict WRITE permissions. Limit s3:PutObject grants to trusted principals. While this reduces the attack surface, it does not eliminate the vulnerability since any user with WRITE permission can exploit it with only their access key.

MinIO is a high-performance object storage system. Starting in RELEASE.2023-05-18T00-05-36Z and prior to RELEASE.2026-04-11T03-20-12Z, an authentication bypass vulnerability in MinIO's Snowball auto-extract handler (PutObjectExtractHandler) allows any user who knows a valid access key to write arbitrary objects to any bucket without knowing the secret key or providing a valid cryptographic signature. Any MinIO deployment is impacted. The attack requires only a valid access key (the well-known default minioadmin, or any key with WRITE permission on a bucket) and a target bucket name. When authTypeStreamingUnsignedTrailer support was added, the new auth type was handled in PutObjectHandler and PutObjectPartHandler but was never added to PutObjectExtractHandler. The snowball auto-extract handler's switch rAuthType block has no case for authTypeStreamingUnsignedTrailer, so execution falls through with zero signature verification. The isPutActionAllowed call before the switch extracts the access key and checks IAM permissions, but does not verify the cryptographic signature. An attacker sends a PUT request with X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER, X-Amz-Meta-Snowball-Auto-Extract: true, and an Authorization header containing a valid access key with a completely fabricated signature. The request is accepted and the tar payload is extracted into the bucket. Users of the open-source minio/minio project should upgrade to MinIO AIStor RELEASE.2026-04-11T03-20-12Z or later. If upgrading is not immediately possible, block unsigned-trailer requests at the load balancer. Reject any request containing X-Amz-Content-Sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER at the reverse proxy or WAF layer. Clients can use STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER (the signed variant) instead. Alternatively, restrict WRITE permissions. Limit s3:PutObject grants to trusted principals. While this reduces the attack surface, it does not eliminate the vulnerability since any user with WRITE permission can exploit it with only their access key.

MinIO is a Kubernetes native application for cloud storage. Prior to version RELEASE.2021-12-27T07-23-18Z, a malicious client can hand-craft an HTTP API call that allows for updating policy for a user and gaining higher privileges. The patch in version RELEASE.2021-12-27T07-23-18Z changes the accepted request body type and removes the ability to apply policy changes through this API.

Minio is a Kubernetes native application for cloud storage. All users on release RELEASE.2021-10-10T16-53-30Z are affected by a vulnerability that involves bypassing policy restrictions on regular users. Normally, checkKeyValid() should return owner true for rootCreds. In the affected version, policy restriction did not work properly for users who did not have service (svc) or security token service (STS) accounts. This issue is fixed in RELEASE.2021-10-13T00-23-17Z. A downgrade back to release RELEASE.2021-10-08T23-58-24Z is available as a workaround.

Minio is a Multi-Cloud Object Storage framework. Affected versions do not correctly honor a Deny policy on ByPassGoverance. Ideally, minio should return "Access Denied" to all users attempting to DELETE a versionId with the special header X-Amz-Bypass-Governance-Retention: true. However, this was not honored instead the request will be honored and an object under governance would be incorrectly deleted. All users are advised to upgrade. There are no known workarounds for this issue.

Impact This is a high priority vulnerability and users must upgrade ASAP.

The signature component of the authorization may be invalid, which would mean that as a client you can use any arbitrary secret to upload objects given the user already has prior WRITE permissions on the bucket,

Prior knowledge of access-key, and bucket name this user might have access to - and an access-key with a WRITE permissions is necessary.

However with relevant information in place, uploading random objects to buckets is trivial and easy via curl

Patches Yes https://github.com/minio/minio/pull/21103

Workarounds Reject requests with x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER for now at LB layer, ask application users to use STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER

Description In minio-java versions prior to 8.6.0, XML tag values containing references to system properties or environment variables were automatically substituted with their actual values during processing. This unintended behavior could lead to the exposure of sensitive information, including credentials, file paths, or system configuration details, if such references were present in XML content from untrusted sources.

Affected Versions - minio-java < 8.6.0

All applications utilizing affected versions of minio-java for parsing XML with potentially untrusted input are vulnerable.

Impact This vulnerability poses a high risk of information disclosure. Attackers could craft malicious XML inputs to extract sensitive data from the system's properties or environment variables, potentially compromising security in applications relying on minio-java for object storage operations.

Patches The issue is resolved in minio-java version 8.6.0 and later. In these versions, automatic substitution of XML tag values with system properties or environment variables has been disabled.

Users are strongly advised to upgrade to minio-java 8.6.0 or a newer release to mitigate the vulnerability.

Workarounds No full workarounds exist without upgrading the library. As interim measures:

- Refrain from processing XML data from untrusted or external sources. - Implement input sanitization or validation to detect and remove references to system properties or environment variables in XML content.

Summary A privilege escalation vulnerability allows service accounts and STS (Security Token Service) accounts with restricted session policies to bypass their inline policy restrictions when performing "own" account operations, specifically when creating new service accounts for the same user.

Details The vulnerability exists in the IAM policy validation logic in cmd/iam.go. When validating session policies for restricted accounts performing operations on their own account (such as creating service accounts), the code incorrectly relied on the DenyOnly argument.

The DenyOnly flag is used to allow accounts to perform actions related to their own account by only checking if the action is explicitly denied. However, when a session policy (sub-policy) is present, the system should validate that the action is actually allowed by the session policy, not just that it isn't denied.

Attack Scenario 1. An administrator creates a service account or STS account with a restricted inline policy (e.g., access only to bucket1 and bucket2) 2. The restricted account attempts to create a new service account for itself without specifying any policy restrictions 3. Due to the bypass, the new service account is created with full parent privileges instead of being restricted by the inline policy 4. The attacker now has escalated privileges beyond the intended restrictions

Impact

Attack Complexity: LOW - Exploitation requires only valid credentials for a restricted service/STS account

Confidentiality: HIGH - Attackers can access buckets and objects beyond their intended restrictions

Integrity: HIGH - Attackers can modify, delete, or create objects outside their authorized scope

Availability: NONE - Does not directly impact service availability

Patches Fixed in PR https://github.com/minio/minio/pull/21642 Commit: c1a49490c78e9c3ebcad86ba0662319138ace190

Install the release go install -v github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z

Workarounds No workarounds available. You can upgrade to the latest version immediately.

Mitigation Steps

1. Upgrade MinIO: Update to the latest version containing the fix 2. Audit Service Accounts: Review all service accounts created by non-admin accounts 3. Revoke Suspicious Accounts: Delete any service accounts that may have been created through exploitation 4. Review Access Logs: Check for unauthorized access to sensitive buckets

Resources

- Fix PR: https://github.com/minio/minio/pull/21642 - Affected code: cmd/iam.go (functions: isAllowedBySessionPolicyForServiceAccount, isAllowedBySessionPolicy)

MinIO is an open-source high performance object storage service and it is API compatible with Amazon S3 cloud storage service. In MinIO before version RELEASE.2021-03-04T00-53-13Z it is possible to bypass a readOnly policy by creating a temporary 'mc share upload' URL. Everyone is impacted who uses MinIO multi-users. This is fixed in version RELEASE.2021-03-04T00-53-13Z. As a workaround, one can disable uploads with Content-Type: multipart/form-data as mentioned in the S3 API RESTObjectPOST docs by using a proxy in front of MinIO.

MinIO is a High Performance Object Storage released under Apache License v2.0. In MinIO before version RELEASE.2021-01-30T00-20-58Z there is a server-side request forgery vulnerability. The target application may have functionality for importing data from a URL, publishing data to a URL, or otherwise reading data from a URL that can be tampered with. The attacker modifies the calls to this functionality by supplying a completely different URL or by manipulating how URLs are built (path traversal etc.). In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases, or perform post requests towards internal services which are not intended to be exposed. This is fixed in version RELEASE.2021-01-30T00-20-58Z, all users are advised to upgrade. As a workaround you can disable the browser front-end with "MINIOBROWSER=off" environment variable.

MinIO contains a vulnerability in a cluster deployment where MinIO returns all environment variables, which allows for information disclosure.

Minio Inc. Minio S3 server version prior to RELEASE.2018-05-16T23-35-33Z contains a Allocation of Memory Without Limits or Throttling (similar to CWE-774) vulnerability in write-to-RAM that can result in Denial of Service. This attack appear to be exploitable via Sending V4-(pre)signed requests with large bodies . This vulnerability appears to have been fixed in after commit 9c8b7306f55f2c8c0a5c7cea9a8db9d34be8faa7.

MinIO is a multi-cloud object storage solution. Starting with version RELEASE.2019-09-25T18-25-51Z and ending with version RELEASE.2022-06-02T02-11-04Z, MinIO is vulnerable to an unending go-routine buildup while keeping connections established due to HTTP clients not closing the connections. Public-facing MinIO deployments are most affected. Users should upgrade to RELEASE.2022-06-02T02-11-04Z to receive a patch. One possible workaround is to use a reverse proxy to limit the number of connections being attempted in front of MinIO, and actively rejecting connections from such malicious clients.

MinIO is a High Performance Object Storage released under GNU Affero General Public License v3.0. In affected versions all 'admin' users authorized for admin:ServerUpdate can selectively trigger an error that in response, returns the content of the path requested. Any normal OS system would allow access to contents at any arbitrary paths that are readable by MinIO process. Users are advised to upgrade. Users unable to upgrade may disable ServerUpdate API by denying the admin:ServerUpdate action for your admin users via IAM policies.

Impact

What kind of vulnerability is it? Who is impacted?

A flaw in extractMetadataFromMime() allows any authenticated user with s3:PutObject permission to inject internal server-side encryption metadata into objects by sending crafted X-Minio-Replication- headers on a normal PutObject request. The server unconditionally maps these headers to X-Minio-Internal- encryption metadata without verifying that the request is a legitimate replication request. Objects written this way carry bogus encryption keys and become permanently unreadable through the S3 API.

Any authenticated user or service with s3:PutObject permission on any bucket can make objects permanently unreadable by injecting fake SSE encryption metadata. The attacker sends a standard PutObject request with X-Minio-Replication-Server-Side-Encryption- headers but without the X-Minio-Source-Replication-Request header that marks legitimate replication traffic. The server maps these headers to internal encryption metadata (X-Minio-Internal-Server-Side-Encryption-Sealed-Key, etc.), causing all subsequent GetObject and HeadObject calls to treat the object as encrypted with keys that do not exist.

This is a targeted denial-of-service vulnerability. An attacker can selectively corrupt individual objects or entire buckets. The ReplicateObjectAction IAM permission is never checked because the request is a normal PutObject, not a replication request.

Affected component: cmd/handler-utils.go, function extractMetadataFromMime().

Affected Versions

All MinIO releases through the final release of the minio/minio open-source project.

The vulnerability was introduced in commit 468a9fae83e965ecefa1c1fdc2fc57b84ece95b0 ("Enable replication of SSE-C objects", PR #19107, 2024-03-28). The first affected release is RELEASE.2024-03-30T09-41-56Z.

Patches

Fixed in: MinIO AIStor RELEASE.2026-03-26T21-24-40Z

Binary Downloads

| Platform | Architecture | Download | | -------- | ------------ | -------- | | Linux | amd64 | minio | | Linux | arm64 | minio | | macOS | arm64 | minio | | macOS | amd64 | minio | | Windows | amd64 | minio.exe |

FIPS Binaries

| Platform | Architecture | Download | | -------- | ------------ | -------- | | Linux | amd64 | minio.fips | | Linux | arm64 | minio.fips |

Package Downloads

| Format | Architecture | Download | | ------ | ------------ | -------- | | DEB | amd64 | minio20260326212440.0.0amd64.deb | | DEB | arm64 | minio20260326212440.0.0arm64.deb | | RPM | amd64 | minio-20260326212440.0.0-1.x8664.rpm | | RPM | arm64 | minio-20260326212440.0.0-1.aarch64.rpm |

Container Images

bash Standard docker pull quay.io/minio/aistor/minio:RELEASE.2026-03-26T21-24-40Z podman pull quay.io/minio/aistor/minio:RELEASE.2026-03-26T21-24-40Z

FIPS docker pull quay.io/minio/aistor/minio:RELEASE.2026-03-26T21-24-40Z.fips podman pull quay.io/minio/aistor/minio:RELEASE.2026-03-26T21-24-40Z.fips

Homebrew (macOS)

bash brew install minio/aistor/minio

Workarounds

Users of the open-source minio/minio project should upgrade to MinIO AIStor RELEASE.2026-03-26T21-24-40Z or later.

If upgrading is not immediately possible:

- Restrict replication headers at a reverse proxy / load balancer. Drop or reject any request containing X-Minio-Replication-Server-Side-Encryption- headers that does not also carry X-Minio-Source-Replication-Request. This blocks the injection path without modifying the server.

- Audit IAM policies. Limit s3:PutObject grants to trusted principals. While this reduces the attack surface, it does not eliminate the vulnerability since any authorized user can exploit it.

References

- Introducing commit: 468a9fae8 (PR #19107) - MinIO AIStor

Impact

What kind of vulnerability is it? Who is impacted?

MinIO's S3 Select feature is vulnerable to memory exhaustion when processing CSV files containing lines longer than available memory. The CSV reader's nextSplit() function calls bufio.Reader.ReadBytes('\n') with no size limit, buffering the entire input in memory until a newline is found. A CSV file with no newline characters causes the entire contents to be read into a single allocation, leading to an OOM crash of the MinIO server process.

This is exploitable by any authenticated user with s3:PutObject and s3:GetObject permissions. The attack is especially practical when combined with compression: a ~2 MB gzip-compressed CSV can decompress to gigabytes of data without newlines, allowing a small upload to cause large memory consumption on the server. However, compression is not required — a sufficiently large uncompressed CSV with no newlines triggers the same issue.

Affected component: internal/s3select/csv/reader.go, function nextSplit().

CWE: CWE-770 (Allocation of Resources Without Limits or Throttling)

Affected Versions

All MinIO releases are through the final release of the minio/minio open-source project.

The vulnerability was introduced in commit https://github.com/minio/minio/commit/7c14cdb60e53dbfdad2be644dfb180cab19fffa7, which added S3 Select support for CSV. The CSV reader has used unbounded line reads since this commit (originally via Go's stdlib encoding/csv.Reader, later via bufio.Reader.ReadBytes after a refactor in PR #8200.

The first affected release is RELEASE.2018-08-18T03-49-57Z.

Patches

Fixed in: MinIO AIStor RELEASE.2025-12-20T04-58-37Z

The fix replaces the unbounded bufio.Reader.ReadBytes('\n') call with a byte-at-a-time loop that caps line scanning at 128 KB (csvSplitSize). If no newline is found within this limit, the reader returns an error instead of continuing to buffer.

Binary Downloads

| Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | minio | | Linux | arm64 | minio | | macOS | arm64 | minio | | macOS | amd64 | minio | | Windows | amd64 | minio.exe |

FIPS Binaries

| Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | minio.fips | | Linux | arm64 | minio.fips |

Package Downloads

| Format | Architecture | Download | | ------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | DEB | amd64 | minio20251220045837.0.0amd64.deb | | DEB | arm64 | minio20251220045837.0.0arm64.deb | | RPM | amd64 | minio-20251220045837.0.0-1.x8664.rpm | | RPM | arm64 | minio-20251220045837.0.0-1.aarch64.rpm |

Container Images

bash Standard docker pull quay.io/minio/aistor/minio:RELEASE.2025-12-20T04-58-37Z podman pull quay.io/minio/aistor/minio:RELEASE.2025-12-20T04-58-37Z

FIPS docker pull quay.io/minio/aistor/minio:RELEASE.2025-12-20T04-58-37Z.fips podman pull quay.io/minio/aistor/minio:RELEASE.2025-12-20T04-58-37Z.fips

Homebrew (macOS)

bash brew install minio/aistor/minio

Workarounds

- Users of the open-source minio/minio project should upgrade to MinIO AIStor RELEASE.2025-12-20T04-58-37Z or later.

If upgrading is not immediately possible:

- Disable S3 Select access via IAM policy. Deny the s3:GetObject action with a condition restricting s3:prefix on sensitive buckets, or more specifically, deny SelectObjectContent requests at a reverse proxy by blocking POST requests with ?select&select-type=2 query parameters.

- Restrict PutObject permissions. Limit s3:PutObject grants to trusted principals to reduce the attack surface. Note: this reduces risk but does not eliminate the vulnerability since any authorized user can exploit it.

References

- Introducing commit: 7c14cdb60 (PR #6127) - MinIO AIStor

MinIO Java SDK is a Simple Storage Service (aka S3) client to perform bucket and object operations to any Amazon S3 compatible object storage service. In minio-java versions prior to 8.6.0, XML tag values containing references to system properties or environment variables were automatically substituted with their actual values during processing. This unintended behavior could lead to the exposure of sensitive information, including credentials, file paths, or system configuration details, if such references were present in XML content from untrusted sources. This is fixed in version 8.6.0.

Impact

What kind of vulnerability is it? Who is impacted?

A path traversal vulnerability in MinIO's ReadMultiple internode storage-REST endpoint allows a caller holding the cluster root JWT to read files from outside the configured drive roots, bounded only by the MinIO process UID.

Distributed-erasure (multi-node) MinIO deployments are impacted. Single-node standalone deployments do not register the route and are not affected. The attack requires an HS512 JWT signed with MINIOROOTPASSWORD and carrying accessKey = MINIOROOTUSER — the same secret every peer in the cluster holds to authenticate internode traffic, so a compromised peer or any actor in possession of the root credential can mint one.

The ReadMultiple handler (cmd/storage-rest-server.go) decodes a msgpack ReadMultipleReq body containing Bucket, Prefix, and Files fields and forwards them to xlStorage.ReadMultiple (cmd/xl-storage.go) without validation:

go volumeDir := pathJoin(s.drivePath, req.Bucket) // traversal resolves here for , f := range req.Files { fullPath := pathJoin(volumeDir, req.Prefix, f) data, mt, err = s.readAllDataWithDMTime(ctx, req.Bucket, volumeDir, fullPath) }

pathJoin calls path.Clean, which resolves .. components and produces an absolute path anywhere on the filesystem — it is not a root jail. The global setRequestValidityMiddleware rejects .. in r.URL.Path and r.Form but does not inspect request bodies, so msgpack-encoded traversal bypasses it. Sibling storage methods (StatInfoFile, ReadFileHandler, ReadVersion) validate their volume argument through s.getVolDir(volume), which rejects ..; ReadMultiple skips this call.

The attacker sends POST /minio/storage/{drivePath}/v63/rmpl with a msgpack-encoded body carrying ../ sequences in the Bucket field. The server opens the resulting path via os.OpenFile with ORDONLY|ONOATIME and returns its contents in the msgpack response stream.

Impact by deployment:

- Bare-metal with User=minio in the systemd unit — the ONOATIME ownership check bounds the read to files owned by the MinIO UID. Reachable secrets include TLS private keys, KMS/KES key material, systemd credentials, and data belonging to other tenants sharing the same UID on the host. Secrets leaked this way persist across cluster credential rotation.

- Containerized running as UID 0 (the historical default for the official Docker image, docker-compose examples, and Helm charts without securityContext.runAsNonRoot) — the primitive escalates to arbitrary host-filesystem disclosure: /etc/shadow, /root/, Kubernetes service-account tokens, cloud-init metadata caches.

Affected components: cmd/storage-rest-server.go (ReadMultiple handler), cmd/xl-storage.go (xlStorage.ReadMultiple).

CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory — 'Path Traversal')

CVSS v4.0 Score: 6.9 (Medium)

Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Affected Versions

All MinIO releases from RELEASE.2022-07-24T01-54-52Z through the final release of the minio/minio open-source project, RELEASE.2025-09-07T16-13-09Z.

The vulnerability was introduced in commit f939d1c18 ("Independent Multipart Uploads", PR #15346), which added the ReadMultiple storage-REST endpoint as part of the multipart upload redesign. The first affected release is RELEASE.2022-07-24T01-54-52Z.

Patches

Fixed in: MinIO AIStor RELEASE.2026-04-14T21-32-45Z (recommended upgrade target). The fix — which removed the ReadMultiple handler, the corresponding storage-driver method, the msgpack datatypes, the REST-client wrapper, and the route registration — first shipped in MinIO AIStor RELEASE.2024-10-23T19-38-07Z. Every AIStor release from RELEASE.2024-10-23T19-38-07Z onward is unaffected; users should upgrade to RELEASE.2026-04-14T21-32-45Z or later to pick up the accumulated fixes and improvements shipped since.

Binary Downloads

| Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | minio | | Linux | arm64 | minio | | macOS | arm64 | minio | | macOS | amd64 | minio | | Windows | amd64 | minio.exe |

FIPS Binaries

| Platform | Architecture | Download | | -------- | ------------ | --------------------------------------------------------------------------- | | Linux | amd64 | minio.fips | | Linux | arm64 | minio.fips |

Package Downloads

| Format | Architecture | Download | | ------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | DEB | amd64 | minio20260414213245.0.0amd64.deb | | DEB | arm64 | minio20260414213245.0.0arm64.deb | | RPM | amd64 | minio-20260414213245.0.0-1.x8664.rpm | | RPM | arm64 | minio-20260414213245.0.0-1.aarch64.rpm |

Container Images

bash Standard docker pull quay.io/minio/aistor/minio:RELEASE.2026-04-14T21-32-45Z podman pull quay.io/minio/aistor/minio:RELEASE.2026-04-14T21-32-45Z

FIPS docker pull quay.io/minio/aistor/minio:RELEASE.2026-04-14T21-32-45Z.fips podman pull quay.io/minio/aistor/minio:RELEASE.2026-04-14T21-32-45Z.fips

Homebrew (macOS)

bash brew install minio/aistor/minio

Workarounds

- Users of the open-source minio/minio project should upgrade to MinIO AIStor RELEASE.2026-04-14T21-32-45Z or later.

If upgrading is not immediately possible:

- Rotate the root credential and restrict who holds it. The exploit requires a JWT signed with MINIOROOTPASSWORD. Treat the root credential as the host-filesystem disclosure primitive that it is: rotate it after any suspected exposure, store it only in the secret manager that bootstraps the cluster, and do not hand it to applications or operators who only need object-level access.

- Do not run the MinIO container as UID 0. Set securityContext.runAsNonRoot: true (and a non-zero runAsUser) in Kubernetes manifests, or add --user to docker run. This reduces the blast radius from arbitrary host-filesystem disclosure to MinIO-UID-owned files only.

- Restrict the internode storage-REST port at the network layer. In distributed deployments, the storage-REST route is served on the same port as the S3 API by default. Where feasible, use --internode-port to expose internode traffic on a separate interface reachable only from other cluster peers, and block that interface from client networks.

Credits

- Finders: Discovered by Claude, Anthropic's AI assistant, and triaged by Adrian Denkiewicz at Doyensec in collaboration with Anthropic Research.

Resources

- Introducing commit: f939d1c18 (PR #15346) - CWE-22 — Improper Limitation of a Pathname to a Restricted Directory - CVE-2022-35919 — MinIO admin-authenticated path traversal in server-update endpoint (same class, different channel) - MinIO AIStor

MinIO is an open-source high performance object storage service and it is API compatible with Amazon S3 cloud storage service. In MinIO before version RELEASE.2021-03-17T02-33-02Z, there is a vulnerability which enables MITM modification of request bodies that are meant to have integrity guaranteed by chunk signatures. In a PUT request using aws-chunked encoding, MinIO ordinarily verifies signatures at the end of a chunk. This check can be skipped if the client sends a false chunk size that is much greater than the actual data sent: the server accepts and completes the request without ever reaching the end of the chunk + thereby without ever checking the chunk signature. This is fixed in version RELEASE.2021-03-17T02-33-02Z. As a workaround one can avoid using "aws-chunked" encoding-based chunk signature upload requests instead use TLS. MinIO SDKs automatically disable chunked encoding signature when the server endpoint is configured with TLS.

Minio is a Multi-Cloud Object Storage framework. Starting with RELEASE.2020-12-23T02-24-12Z and prior to RELEASE.2023-03-13T19-46-17Z, a user with consoleAdmin permissions can potentially create a user that matches the root credential accessKey. Once this user is created successfully, the root credential ceases to work appropriately. The issue is patched in RELEASE.2023-03-13T19-46-17Z. There are ways to work around this via adding higher privileges to the disabled root user via mc admin policy set.

Impact Unicode RIGHT-TO-LEFT OVERRIDE characters can be used to mask the original filename.

Reported-By Thanks to the report from Mio Li wulilixi1@gmail.com

Patches commit 17e791afb90c9ad27c65f63c6be14f2f6a3a9d60 Author: Daniel Valdivia <18384552+dvaldivia@users.noreply.github.com> Date: Tue May 23 08:47:12 2023 -0700

Replace RIGHT-TO-LEFT OVERRIDE unicode (#2828) Signed-off-by: Daniel Valdivia <18384552+dvaldivia@users.noreply.github.com>

Workarounds Workarounds are to remove the concerned file and rewrite it properly with the right file and extensions. Avoid using RTLO characters in your filenames.

Summary A bug in evaluating the trust of the SSH key used in an SFTP connection to MinIO allows authentication bypass and unauthorized data access.

Details

On a MinIO server with SFTP access configured and using LDAP as an external identity provider, MinIO supports SSH key based authentication for SFTP connections when the user has the sshPublicKey attribute set in their LDAP server. The server trusts the client's key only when the public key is the same as the sshPublicKey attribute.

Due to the bug, when the user has no sshPublicKey property in LDAP, the server ends up trusting the key allowing the client to perform any FTP operations allowed by the MinIO access policies associated with the LDAP user (or any of their groups).

The bug was introduced in https://github.com/minio/minio/commit/91e1487de45720753c9e9e4c02b1bd16b7e452fa.

Impact

The following requirements must be met to exploit this vulnerability:

1. MinIO server must be configured to allow SFTP access and use LDAP as an external identity provider. 2. Knowledge of an LDAP username that does not have the sshPublicKey property set. 3. Such an LDAP username or one of their groups must also have some MinIO access policy configured.

When this bug is successfully exploited, the attacker can perform any FTP operations (i.e. reading, writing, deleting and listing objects) allowed by the access policy associated with the LDAP user account (and their groups).