Garage fingerprinting needs to separate S3 from its admin API
Garage is a self-hosted, S3-compatible object store designed for small clusters spread across locations. It exposes an S3 data path, an inter-node RPC channel, and an administrative API. A search result that identifies Garage does not tell an analyst whether the public listener is the object API, a web front end, or the administration surface. The ports and authorization model must be checked separately.
A standalone ZoomEye SDK query using sub_type=all, page 1, and page size 1 returned 19 matches for app="Garage" and 52,522 for title="Garage" on 30 October 2026 at 00:40 UTC. The large difference is a warning about generic words. "Garage" appears in ordinary web pages, so the title count cannot stand in for a product inventory. The app query is narrower, but it is still a fingerprint observation rather than proof that a cluster is vulnerable.
Review each listener
Garage's documented deployment uses the S3 API on port 3900, the RPC channel on port 3901, and the Admin API on port 3903, with deployment templates binding administrative listeners to loopback or a management network where possible. An S3 endpoint may need public or partner access. The admin API supports cluster and access-control changes and should have a stronger boundary.
Check the bind addresses, container port publishing, reverse-proxy routes, firewall rules, and TLS termination for each service. The admin token is a bearer credential for the administration path, so its storage and rotation need the same care as an S3 secret key. An admin token in a browser bundle or a public configuration file gives away the management plane even when the S3 endpoint looks well controlled.
Treat bucket policy as part of the data boundary
An S3-compatible API can host both public distribution content and private backups. Review bucket policies, access keys, object ownership, and anonymous access separately. If objects are served through a web tier, check whether the web tier adds authentication or merely proxies a public bucket. Confirm that bucket listings are not exposed where the workload does not need them.
Use separate credentials for applications that read objects, applications that write objects, and automation that changes bucket configuration. Garage access keys can often be scoped to a key and bucket combination; use that capability instead of a shared cluster-wide key. Rotate a key after a suspected leak and verify that the old key is rejected.
Build an evidence trail
For each owned deployment, record the query that identified it, the public IP or hostname, the port and protocol observed, and the service that answered. Compare that with the intended network exposure. Do not connect to an unrelated server or attempt a write. A public S3 endpoint that returns an access-denied response still confirms a listener and can be recorded as an exposure observation.
The useful inventory combines product identity with service role. On Garage, the difference between the S3 API and the admin API is the difference between a controlled data share and a cluster-management path.
Top comments (0)