S3Scanner: Finding Open Buckets Across S3-Compatible Providers

What S3Scanner checks, and what it assumes you already have

S3Scanner answers one narrow question: given a bucket name, is that bucket misconfigured in a way that exposes it? The README describes it as "A tool to find open S3 buckets in AWS or other cloud providers" and lists AWS, DigitalOcean, DreamHost, GCP, Linode, Scaleway and a custom option as the supported targets. The audience is clear from the repository topics: aws, bugbounty, gcp, infosec. This is a tool for penetration testers, bug bounty hunters and cloud security engineers who work from a candidate list.

The assumption matters more than the feature list. Input is one of -bucket, -bucket-file or -mq, and the usage block marks exactly one as required. There is no permutation engine here, no wordlist expansion, no DNS or certificate transparency harvesting. If you do not have names to feed it, S3Scanner is the wrong end of the pipeline. The README also points to a discussions page as the project homepage, which is where questions and provider requests appear to be routed rather than an issue tracker alone.

How the scan pipeline is put together

The top-level repository layout reads like a pipeline: cmd/ for the command line, worker/ for the scan workers, bucket/ for bucket handling, permission/ for permission checks, provider/ for provider-specific behaviour, and then mq/, db/, collection/, groups/ and log/ for the surrounding infrastructure. That separation is the clearest signal of how the tool is meant to be used at scale: names come in from a file or from RabbitMQ, workers process them, permission results are produced, and results can be written to Postgres.

The dependency list confirms the mechanism rather than contradicting it. The AWS SDK for Go v2 with the S3 service package is the main client, github.com/streadway/amqp is the RabbitMQ client, gorm.io/gorm with gorm.io/driver/postgres handles persistence, and github.com/spf13/viper reads configuration. The scanning is multi-threaded, controlled by -threads, which defaults to 4. That default is conservative on purpose: raising it against a provider that rate-limits anonymous requests will produce failures rather than faster results, and the README does not document a backoff strategy or a retry policy for throttled responses.

Installing S3Scanner and running a first scan

The README's installation table covers a wide spread of package managers. On Debian-derived distributions including Kali and Parrot OS the package is available directly, and Homebrew covers macOS. The Go route installs the latest tagged source. Pick one and confirm the binary answers before scanning anything.

go install -v github.com/sa7mon/s3scanner@latest
s3scanner -version

The version flag prints the build version, which is how you confirm the install worked. The same install is available through Docker as ghcr.io/sa7mon/s3scanner, and through pacman, apt, brew, winget and nix-shell depending on platform.

The first real scan is a bucket file against AWS, with object enumeration switched on. Enumeration is the expensive part, so the README's own quick start pairs it with a file input rather than a single bucket.

s3scanner -bucket-file names.txt -enumerate

With no -provider flag the tool defaults to aws, and with no -threads flag it uses 4 workers. Output is human-readable unless -json is passed, in which case logs go to stdout as JSON. If you want to scan a GCP bucket and persist the result, the README gives this two-flag form:

s3scanner -provider gcp -db -bucket my-bucket -enumerate

The -db flag requires a db.uri key in the config file, and the tool searches for config.yml in three places: the current directory, /etc/s3scanner/ and $HOME/.s3scanner/. If none of those contains the file, the database write has nothing to connect with. The -provider custom value likewise requires the config file, since a custom endpoint cannot be guessed.

Where S3Scanner stops being useful

The most obvious limitation is the one the usage block states plainly: input is required and it is a name. S3Scanner does not find bucket names. Teams that expect a scanner to sweep a provider and return a list of exposed buckets will be disappointed, because that is a different class of tool. What this does is take names you supply, whether from a prior reconnaissance step, an internal inventory, or a RabbitMQ queue, and tell you what permissions those buckets expose.

Enumeration is the second constraint. The README labels -enumerate as potentially time-consuming, and that warning is honest: listing objects means paginated requests per bucket, so a large bucket file combined with enumeration and the default 4 threads will run for a long time. Turning enumeration off gives you the permission result faster, but then you know a bucket is open without knowing what is inside it.

The provider list is the third boundary. AWS, DigitalOcean, DreamHost, GCP, Linode and Scaleway are built in. Anything else has to go through -provider custom with a config file, and the README does not document what keys that custom configuration requires. The go.mod file shows a goquery dependency, which suggests some provider handling involves parsing HTML rather than a clean API, but the README does not explain which providers rely on that path, so treat it as an implementation detail rather than a documented behaviour.

S3Scanner compared with discovery-first tools

The related searches around this project name several tools that solve the opposite problem. Lazys3, AWSBucketDump, CloudBrute and S3recon all start from wordlists or permutation logic and generate candidate names before testing them. Grayhatwarfare and the online bucket search services take a third approach entirely: they maintain an index of buckets that already exist and let you query it, which means you are searching someone else's crawl rather than scanning live.

The practical difference is where the name comes from. A discovery tool produces candidates and tests them, which is useful when you have no inventory but noisy when you are checking a known set. S3Scanner assumes the name is already in hand, which makes it a poor first step and a good second one. The index services sit outside that loop: they can suggest names, but the answer about current permissions still comes from a live request, and S3Scanner is the thing that makes that request against multiple providers with one binary.

Maintenance, scaling and the MIT licence

The last push to the repository was on 2026-08-03, which is recent enough that the codebase is not stale, but the release history tells a different story about packaging: v3.1.1 shipped on 2024-09-17, v3.1.0 on 2024-09-08, and v3.0.4 on 2023-09-25. Anyone installing through a distribution package manager is likely to get a build behind the main branch, so check the version the package manager installed against what the repository contains if a flag behaves unexpectedly.

Scaling out is where the operational cost lands. The RabbitMQ path, enabled with -mq, requires an mq key in the config file, and the Postgres path requires db.uri. Both add a service to run and maintain. For a one-off check of a few hundred buckets, neither is worth the setup, and the file input plus JSON output covers the case. The Makefile shows the project's own workflow: docker compose against .dev/docker-compose.yml brings up the development dependencies, and test-coverage runs with TEST_DB=1 and TEST_MQ=1, which confirms that database and queue are treated as real integration surfaces rather than optional extras in the test suite.

The licence is MIT, which permits commercial and closed-source use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, but it is not legal advice: if you redistribute S3Scanner inside a product, have your own counsel read the LICENSE file rather than assuming the summary above is sufficient.

Editorial conclusion

Adopt S3Scanner if you already hold a list of bucket names and need a repeatable permission check against several S3-compatible providers from one binary. Skip it if your problem is discovering bucket names in the first place, since the tool takes names as input and does not generate them. Before relying on it, verify that the provider you care about is one of the built-in values, that your config.yml sits in one of the three searched paths, and that Postgres or RabbitMQ are only enabled if you actually run those services.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sa7mon/S3Scanner on GitHub