261,785 MinIO Fingerprints and the Root Credential That Defaults to minioadmin

Object storage holds the copies. Backups, data lake exports, model artefacts, log archives: the set of things an organisation would most want an intruder not to read, gathered behind one API.
ZoomEye measurements collected on 28 October 2026 show 261,785 assets matching app="MinIO". The number is a measure of how widely the S3-compatible object server has been adopted for private deployments, and it says nothing about whether those deployments authenticate their callers.

The credential the documentation names

MinIO's identity and access management documentation describes the model plainly. Authentication verifies a user or client application; credentials take the form of a username and password, or an access key and secret key, or a call to an STS endpoint. Authorization then decides what the authenticated identity may do.
The same page addresses the root user, and this is the part worth quoting. It lists MINIO_ROOT_USER and MINIO_ROOT_PASSWORD and states that the default value for each is minioadmin.
That default is useful during installation and dangerous afterwards, because the root user is not a normal account. It has full administrative authority over the deployment and cannot be restricted by policy in the way a regular identity can. A server started without those two environment variables set starts with a credential that is published in the documentation.

Why object storage attracts attention

The value of the contents explains the interest. A bucket holding database dumps is a copy of the production data with none of the query logging. A bucket holding backups is the recovery capability itself, which means an intruder who can delete it has removed the organisation's ability to restore without touching the primary systems.
MinIO's own feature set makes the risk more textured. Bucket policies can grant anonymous read on a prefix, which is a documented and legitimate capability used for public artefacts. Lifecycle rules can expire objects, replication can copy them elsewhere, and the STS endpoint can mint temporary credentials with a lifetime. Each of those is a control, and each one has a configuration in which it does the wrong thing.

The measurement question

A fingerprint tells you the software answers. It does not tell you whether a bucket is readable without credentials, and MinIO has no signature for "the root password is still minioadmin". The 261,785 figure should be read as a population of deployments, not a population of findings.
That distinction matters for how an exposure review is scoped. A count that large implies the software is common, which means an organisation's own instances are probably one among many and probably not being watched individually. The interesting question is not how many exist but which ones answer to a request made without a signature.

What to check, in order

Confirm the root credential is not the default. This is a single check, and it should be the first one, because everything else is moot if the answer is yes.
Then look at anonymous access. mc anonymous get against each bucket reports the policy in force. A bucket with public read on a prefix that was meant for build artefacts is fine; the same policy on a prefix holding customer exports is not, and the two look identical until somebody reads the policy.
Review the identities. MinIO distinguishes the root user from regular users, and regular users from STS-issued temporary credentials. A service account with a broad policy is a standing credential that will outlive the job it was created for unless somebody removes it.
Check the network path. An object server used by a fixed set of applications does not need a public endpoint, and the console port is a separate decision from the API port. Publishing the console because it is convenient is a common pattern and a needless one.

The durable point

Defaults that appear in vendor documentation are not oversights. They exist so that an installation can be tested immediately, and most operators change them within the hour. The ones who do not are not usually careless; they are the ones who installed the server to solve a problem, then moved to the next problem and never returned.
A count of 261,785 is a reasonable reminder that the next problem is always there. The check that resolves it takes one command.

References

• MinIO documentation, identity and access management: https://min.io/docs/minio/linux/administration/identity-access-management.html
• ZoomEye query app="MinIO", 2026-10-28: https://www.zoomeye.ai/searchResult?q=YXBwPSJNaW5JTyI%3D Measurement notes: the count was collected on 28 October 2026 through the ZoomEye SDK. It describes indexed assets and does not indicate bucket permissions, credential strength or data sensitivity.