SeaweedFS and the Object Store You Forgot You Deployed: 6,345 Matches

Object storage has become a default component of application architectures, and the assumption that it is provided by a cloud service is not universal. Self-hosted storage layers solve specific problems for teams that run their own infrastructure, and they are frequently deployed as a supporting component rather than as a system that receives an access review.

Method and scope

ZoomEye queries were run on 2026-09-28. The count is the number of assets matching the query at that time. A match confirms a reachable service answering the signature, not a configuration or data classification.

Why a small storage count is worth attention

The container registry count in the previous report in this series described registries as a deployment authority because they hold the artefacts that get deployed. An object store holds the data those applications read and write, which is a related but different authority.

A self-hosted storage layer is typically deployed to serve an application that needed S3-compatible storage without a cloud provider. It often runs on infrastructure the application team controls rather than on a platform team's managed service, which means it inherits whatever network position the application has.

The 6,345 figure is small enough to suggest that most deployments are internal. The subset that is reachable is therefore more likely to be an unintended exposure than a deliberate design, which is the same pattern described in the earlier reports on private code hosting and internal dashboards.

What to check

An S3-compatible gateway has a small number of settings that decide whether an exposure matters. Whether the identity and access configuration is enabled at all, because some deployments run without access control on the assumption that the network provides it. Whether the administrative interface, which is often served on a different port from the data API, is reachable on the same address. Whether the data API requires a signature on every request.

The network question is the one to answer first, because it determines whether the other settings are reachable at all. A storage service that is bound to a container network and reached through the application is in a different position from one with a listening socket on a public address.

Keeping the inventory honest

Services that are deployed as supporting components are the ones most likely to be missing from an inventory, because they are provisioned by the application's deployment tooling rather than by the platform team's process. The practical check is a comparison between what the exposure query returns for the organisation's network space and what the configuration management database records.

A storage endpoint in the first list and not the second is a component that exists without a recorded owner. That is the finding, and it is more useful than a version comparison, because an untracked component is also one that will not be included in the next patch cycle.

References

• SeaweedFS documentation, S3 API: https://github.com/seaweedfs/seaweedfs/wiki/Amazon-S3-API
• ZoomEye documentation: https://www.zoomeye.ai/doc