Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/minio/minio >= 0.0.0-20220724015452, < 0.0.0-20260414213245
Fixed in
0.0.0-20260414213245· Vendor fix available
Issue
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: pathJoin calls path.Clean, which resolves .. components and produces an…
Recommended action: Upgrade to 0.0.0-20260414213245 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/minio/minio < 0.0.0-20251015170045-c1a49490c78e
Fixed in
0.0.0-20251015170045-c1a49490c78e· Vendor fix available
Issue
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…
Recommended action: Upgrade to 0.0.0-20251015170045-c1a49490c78e (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/minio/minio < 0.0.0-20250403145552-8c70975283f9
Fixed in
0.0.0-20250403145552-8c70975283f9· Vendor fix available
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
Recommended action: Upgrade to 0.0.0-20250403145552-8c70975283f9 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/minio/minio >= 0.0.0-20240605075113-91e1487de457, < 0.0.0-20250227184332-4c71f1b4ec0f
Fixed in
0.0.0-20250227184332-4c71f1b4ec0f· Vendor fix available
Issue
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…
Recommended action: Upgrade to 0.0.0-20250227184332-4c71f1b4ec0f (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/minio/minio >= 0.0.0-20220623162515-580d9db85e04, < 0.0.0-20241213221912-68b004a48f41
Fixed in
0.0.0-20241213221912-68b004a48f41· Vendor fix available
Issue
Impact Privilege escalation in IAM import API, all users are impacted since MinIO commit 580d9db85e04f1b63cc2909af50f0ed08afa965f Patches ./minio server /tmp/d{1...4} & mc alias set myminio http://localhost:9000 minioadmin minioadmin mc admin user add myminio nobody nobody123 mc admin policy attach myminio readwrite nobody nobody123 mc alias set nobody http://localhost:9000 nobody nobody123 mc admin cluster iam export myminio mkdir /tmp/x && mv myminio-iam-info.zip /tmp/x cd /tmp/x unzip myminio-iam-info.zip echo '{"nobody":{"version":1,"policy":"consoleAdmin","updatedAt":"2024-08-13T19:47:10.1Z"}}' \ iam-assets/usermappings.json zip -r myminio-iam-info-updated.zip iam-assets/ mc admin cluster iam import nobody ./myminio-iam-info-updated.zip mc admin service restart nobody Workarounds There are no workarounds possible, all users are advised to upgrade immediately if you don't run MinIO behind a load balancer. Behind a load balancer / firewall such as nginx . Following locations can…
Recommended action: Upgrade to 0.0.0-20241213221912-68b004a48f41 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/minio/minio < 0.0.0-20240527191746-e0fe7cc39172
Fixed in
0.0.0-20240527191746-e0fe7cc39172· Vendor fix available
Issue
Impact If-Modified-Since If-Unmodified-Since Headers when used with anonymous requests by sending a random object name requests you can figure out if the object exists or not on the server on a specific bucket and also gain access to some amount of information such as This conditional check was being honored before validating if the anonymous access is indeed allowed on the metadata of an object. Patches Yes this issue has been already fixed in Last-Modified Etag x-amz-version-id Expires: Cache-Control: Users must upgrade to RELEASE.2024-05-27T19-17-46Z for the fix Workarounds There are no workarounds. References Refer to the pull request #19810 for more information on the fix.
Recommended action: Upgrade to 0.0.0-20240527191746-e0fe7cc39172 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/minio/minio < 0.0.0-20240131185645-0ae4915a9391
Fixed in
0.0.0-20240131185645-0ae4915a9391· Vendor fix available
Issue
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. We then set an alias in mc: mcli alias set vuln http://localhost:9001 mycat mycatiscute And checked whether policy works: 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: And then: mycat has…
Recommended action: Upgrade to 0.0.0-20240131185645-0ae4915a9391 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Workarounds There are no known workarounds References The vulnerable code:
Recommended action: Upgrade to 0.0.0-202303200735 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Workarounds Browser API access must be enabled turning off MINIOBROWSER=off allows for this workaround. References The vulnerable code:
Recommended action: Upgrade to 0.0.0-202303200415 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.