492,113 MinIO Titles: Object Storage Is Where the Backups Live
Object storage is the least dramatic exposure class and the most expensive one to get wrong. A web application leaking its front page is an embarrassment. An S3-compatible store leaking its bucket list is every backup, every database dump and every build artifact in a single HTTP response.
Context and method
Counts are from the ZoomEye index, 23 October 2026, sub_type=all, pagesize=1, page 1. Fingerprint matches, not installations.
| Query | Total |
|---|---|
app="MinIO" |
261,617 |
title="MinIO" |
492,113 |
The title query reports 230,496 more matches than the application fingerprint, a gap of 88%. For a product whose console renders the name prominently, that is a large divergence, and it deserves a careful reading rather than a single headline number.
What a MinIO console and a MinIO API are not
MinIO serves two distinct surfaces on the same host: the object API, which is S3-compatible, and a web console where buckets and access keys are administered. They behave differently under scanning.
The console returns an HTML page with the product name in the title. The API returns XML and S3 error codes. An index matching on titles finds every console it can reach and misses API-only deployments entirely, which is one reason a title count can run far ahead of a fingerprint count.
The second reason is packaging. MinIO is frequently deployed as a component inside a larger product, since backup software, artifact caches and analytics platforms ship it as a dependency. A matching title may therefore be a login page belonging to an application whose storage backend happens to be MinIO.
Either way, the two numbers describe different things, and neither is a count of open buckets. A public index cannot enumerate bucket listings; it can only see that a host answered in a way consistent with the product.
Why this asset class carries more weight
Three properties separate object storage from a typical web application.
It accumulates. A web application's database holds current state. An object store holds every state it has ever held, including the dumps taken before migrations and the archives nobody deleted. Reachability in 2026 exposes data from 2021.
Its access model is easy to misconfigure. Bucket policies, anonymous access settings and access key scoping are separate controls, and one permissive policy is enough to expose a whole bucket. The classic failure is not a compromised credential but an intentional public setting that outlived its purpose.
It is quiet. A bucket read is an ordinary GET request. There is no login event, no failed authentication, and in many deployments no log retention long enough to notice systematic enumeration weeks later.
A scoped query plan
- Run both dorks scoped to your own address space. Record the difference between the app and title counts for your organisation, not globally.
- Identify which matches are consoles and which are API endpoints. A console exposure is a credential risk; an API exposure is a data risk. They call for different responses.
- For every console match, confirm that anonymous access is disabled and that the administrator account is not on a default credential set.
- For every API match, test bucket policy rather than the API root. An API root that answers is not the same as a bucket that answers to an unauthenticated GET.
- Check retention. If object access logs are kept for days, an enumeration that happened last month is already unanswerable.
Reading the numbers with the right caution
492,113 title matches is a large population, and the honest reading is narrow: the index found that many hosts whose response carried the product name in a title element. It did not find 492,113 open buckets. Treating the number as an exposure count makes an exposure report useless; treating it as meaningless leaves backups on the internet.
References
- ZoomEye search: https://www.zoomeye.org/
- MinIO documentation on bucket policies and anonymous access: https://min.io/docs/minio/linux/index.html
Top comments (0)