leaker merges credential leak searches across 13 breach APIs

One CLI over thirteen separate breach services

leaker is described as a passive leak enumeration tool, and the README says it returns valid credential leaks using passive online sources, supporting searching by email, username, domain, keyword and phone number. It is created by Maksim Radaev, and the homepage for the project is a post introducing it.

The design is a fan out and a merge. leaker does not host leak data. It holds credentials for the upstream services and calls each one, then normalises the responses and deduplicates them so the same breach appearing in three sources appears once. The source list is published as a table, and it is worth reading as a pricing document: BreachDirectory, DeHashed, Hudson Rock, Intelligence X, LeakCheck, LeakRadar, Leak-Lookup, LeakSight, OSINTLeak, ProxyNova, Snusbase, WeLeakInfo and WhiteIntel.

Of those, the README marks only ProxyNova as free with no key, Hudson Rock as free or paid with a key noted as not required in the table, and everything else as requiring a key, mostly on a paid tier with Intelligence X offering a free tier and BreachDirectory described as free via RapidAPI.

So the tool is an abstraction over paid services, and the value is in the ergonomics: one command, one output format, one deduplication pass, rather than thirteen separate integrations in your own scripts. The primary language is Go, the licence is MIT, the last push was on 2026-10-09, and the release history shows v1.6.7 in June 2026 and v1.6.8 and v1.6.9 on the same day in July.

Five search types, per source rate limits, and a proxy

The command surface is wide, and the help output is the best description of it. The usage block begins:

Usage: leaker <command> [flags]

  leaker is a leak discovery tool that returns valid credential leaks for emails, using passive online sources.

Flags:
  -h, --help                      Show context-sensitive help.
  -s, --sources=online,...        Sources to use for enumeration. 
                                  online (default), all, local, or explicit source names.
  --timeout=30s                   Seconds to wait on each request before timing out
  -N, --no-rate-limit             Disable rate limiting (DANGER)
  -j, --json                      Output results as JSONL (one JSON object per line)
  --no-deduplication              Disable deduplication of results across sources
  --no-filter                     Disable results filtering, include every result
  -o, --output=STRING             File to write output to
  --overwrite                     Force overwrite of existing output file

The five commands mirror the five search types: domain, email, keyword, phone and username, each with its own help text.

Two flags deserve attention because they are the ones that will get you blocked or in trouble. The -N flag disables rate limiting and is labelled DANGER in the help output, and the built in per source rate limits are a feature rather than an inconvenience, since most of these services will throttle or ban an aggressive client. The --insecure flag disables TLS certificate verification, and the help text marks it as use with caution.

The -s flag is how you control cost and noise, with online as the default, plus all, local, or explicit source names. The local option is the one that most affects behaviour, since it implies the local SQLite cache is usable as a source in its own right, which is how you work with the cached data you already have.

The remaining flags cover the plumbing: --proxy for an HTTP proxy, -A for a custom user agent, --timeout per request, --db for the cache path, --no-write-db to stop caching, -M for metadata fields such as the database name, -q for quiet, -v for verbose, -D for debug, --no-color, and -L to list all available sources.

Deduplication, filtering and the local SQLite cache

Three features decide whether the output is usable, and all three are about not drowning in duplicates.

Deduplication removes duplicate results across sources, and it can be turned off with --no-deduplication. Filtering is separate, with --no-filter described as disabling results filtering and including every result. The distinction matters in practice, because a raw hit from a breach database is often a duplicate of a different record, and without deduplication the same email will appear several times in a report with slightly different fields.

The local cache is a SQLite database, with modernc.org/sqlite as the driver, so it is a pure Go implementation with no cgo and no system library. The path is set with --db, and writing to it can be disabled with --no-write-db. This is the mechanism behind the local source, and it is the reason the tool can be run repeatedly against the same target without paying for the same queries twice.

The credential verification flag is the other thing that makes the results worth having. The -V flag is described as verifying credentials using HIBP password check and hash identification, which is the Have I Been Pwned range API: you send a hash prefix, and the service tells you whether a password with that prefix exists in its corpus, without receiving the password itself.

That distinction is what separates a list of records that mention a password from a list of records where the password is real. For exposure research, the difference between a leaked record and a working credential is the difference between a report line and an incident.

Installing it with go install, or running the container

Installation is a single Go install, and the version requirement is explicit: leaker requires go1.24 to install successfully.

go install -v github.com/vflame6/leaker@latest

There is a container image as well, and the Dockerfile in the repository is a two stage build. The builder is golang:1.25-alpine with build-base installed, and it copies go.mod, downloads the modules, copies the source and builds the binary. The final stage is alpine:latest, upgraded and given bind-tools and ca-certificates, with a dedicated unprivileged user created with adduser using uid 1000 and the nologin shell, and the leaker binary copied to /usr/local/bin. The entrypoint is simply leaker.

The runtime image is deliberately minimal, and the non-root user and the nologin shell are the right defaults for a tool that makes outbound network requests.

Configuration is where the real setup happens. The README notes that leaker can be used right after installation, however many sources require API keys to work, and points at a configuration wiki page for the details. The -p or --provider-config flag takes a provider config file, and the configuration is YAML, with gopkg.in/yaml.v3 as the parser. There is also a key rotation feature described as load balancing across keys per source, which matters for the services that rate limit on API key rather than on IP.

The command line interface is built with kong, and the terminal detection uses go-isatty, which is what drives the colour and quiet behaviour.

Where the money goes: which sources are paid

The source table is the practical planning document, because running a meaningful query means knowing which services you have to pay for.

LeakCheck, LeakRadar, Leak-Lookup, LeakSight, OSINTLeak, Snusbase, WeLeakInfo and WhiteIntel are marked Paid, and all of them require an API key. DeHashed and Intelligence X are also keyed, with Intelligence X offering a free tier and DeHashed marked Paid. Leak-Lookup, LeakSight, OSINTLeak, Snusbase, WeLeakInfo and LeakCheck cover all five search types, while Hudson Rock, LeakRadar and WhiteIntel cover email, username and domain only, and ProxyNova covers all types for free with no key.

That last point is the practical constraint. A single free source that covers every search type lets you evaluate the tool and the shape of the data before committing to a subscription, and a subscription to one of the full type coverage services is what a real workflow needs.

The searching capability also varies by type, and the tool is explicit about it. Some services support the full set, some only email, username and domain, and BreachDirectory is marked as auto-detect for all types. The -s flag lets you name explicit sources, so you can run a free-only sweep and then a paid sweep for the types that need one.

The --proxy flag exists for a reason beyond anonymity, which is network routing. If a service is unreachable from your location, or you need to stay within a corporate egress policy, the proxy is the knob that makes that possible.

What this tool is, and where the line is

leaker sits in the OSINT and breach exposure research category, and the repository topics say so: bugbounty, hacking, leak-detection, leaks, osint and reconnaissance.

What it does is query services that already hold breach data and hand back records that match your search term. What it does not do is scan targets, exploit anything, or obtain credentials for systems you have no relationship with. Every input is a term you supply, and every output is a record that already existed in one of the upstream databases.

The exception in practice is the credential verification path. The -V flag checks a leaked password against the HIBP corpus, and combined with a matched email and a service that returns the surrounding record, the result can be a set of working credentials. The repository anticipates this and points at DISCLAIMER.md for the usage disclaimer, and the topics and the source list make the intended context, bug bounty and exposure research, explicit.

The legal frame follows from the sources. Each of the thirteen services has its own terms, and several of them sell access specifically so that security researchers can query them. Passing a third party's address to a paid API is a use of that service, and the terms of that service govern it, alongside whatever authorisation you have for the data you are searching for.

Practically, the tool is at its most useful for one task: finding out whether a domain, an address or a username you are responsible for appears in known breach data, and then working through the results. The rate limits, the deduplication and the local cache all exist to make that repeatable.

The licence is MIT, the releases are frequent, with v1.6.8 and v1.6.9 published on the same day in July 2026, and the last push was on 2026-10-09.

Editorial conclusion

Adopt leaker if you are doing breach exposure research, checking whether a domain or account appears in known leaks, and you can obtain the API keys the paid sources require. Do not adopt it as a way to obtain working credentials for accounts you do not control, and do not expect a single key to cover the catalogue, since most of the thirteen sources are paid and keyed. Before you run it, read DISCLAIMER.md and the configuration wiki page, set per-source rate limits rather than disabling them, and confirm that querying a third party service on your behalf is permitted by that provider's terms.

Frequently asked questions

Official sources

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