arkadiyt/bounty-targets-data: scope lists for bug bounty programs, refreshed twice an hour

A repository whose entire content is a data directory

The tree is three entries: a LICENSE.md, a README.md and a data directory. There is no source directory, no package manifest, no CI configuration and no build script. Nothing is compiled and nothing needs to be.

The project description says what is inside those data files: hourly-updated dumps of bug bounty platform scopes, specifically the domains that are eligible for reports, across HackerOne, Bugcrowd, Intigriti and others. MIT licensed, 3,959 stars, 672 forks, and zero open issues. That last number is the tell for how this repository is used. People fetch from it. They do not file tickets against it, because there is no interface to disagree with and no behaviour to change.

The default branch is main, and the repository has been pushed to recently, with the last push landing on 2026-09-22. Topics list bounty, bug, hackerone, bugcrowd, intigriti, yeswehack, federacy, hackenproof and vrp, which is a fair map of the platforms covered and one that does not perfectly match the files that are actually published. We will come back to that.

Two flat lists, then five raw dumps

The files split into two groups, and the split matters because it is the difference between a convenient file and the actual source data.

The main files are domains.txt, described as the full list of domains without wildcards, and wildcards.txt, the full list of wildcard domains. Both are plain text, which means you can grep them, diff them between commits, and feed them straight into a wordlist pipeline without writing a parser. If you want to know what is newly in scope this week, diffing the file against last week's commit is the whole workflow.

The extra files are the raw platform data, one JSON file per platform: bugcrowd_data.json, hackerone_data.json, federacy_data.json, intigriti_data.json and yeswehack_data.json. These hold the unflattened material, so whatever structure the platforms actually publish rather than a list reduced to domain strings. If you are building anything that needs program metadata, reward ranges or the shape of a scope entry, you want these. If you just want a list of things to look at, domains.txt is enough.

The wildcard caveat that keeps researchers out of trouble

One warning appears in the README and it is the most practically important sentence in the repository. It notes that a program might have `*.example.com` in scope but `excluded.example.com` out of scope, and instructs you to check your program rules before submitting reports.

This is not pedantry. A flattened domain list cannot represent that distinction, because the whole point of the flat file is that it has thrown away structure. If a program publishes a wildcard plus a list of exclusions, then a scanner that expands wildcards mechanically will eventually touch an excluded host, and the resulting report is a rejected report at best. The raw JSON files are where that exclusion data still exists, which is the practical argument for reading them rather than only the text lists.

The same caveat applies to what counts as a bug. Scope tells you where a program will listen, not what they consider a vulnerability. That part is defined by each program's own rules, which live on the platform and change on the platform's schedule, not here.

How current the data actually is

The README carries a status line rather than a release schedule. It states that the last change was detected on Tuesday 09/22/2026 11:00 UTC, and that new changes, if any, are picked up every 30 minutes.

That interval is worth holding onto when you compare the two descriptions of this project. The GitHub repository description calls the data hourly-updated, while the README says the scraper runs every 30 minutes. Both can be true, since the check can run twice as often as anything actually changes, and a large fraction of runs will produce no commit at all. Read it as a freshness bound of roughly half an hour with commits appearing only when something changed, rather than as a guarantee that a brand new program appears within the hour.

There are no tagged releases in this repository. That is the correct design for a data feed, and it is also why you should not pin to a version. Consuming it means tracking the main branch, which is where the commit timestamps become your freshness signal.

The generator lives somewhere else

The README points out that the code used to generate these files lives in a separate repository, arkadiyt/bounty-targets. The split between generator and data is what allows this repository to have zero open issues and no code, since a scraper that breaks is a problem in the other repository.

It also means this repository tells you almost nothing about method. You are not told which endpoints are queried, how aggressively it rate limits, how it handles a platform that changes its page structure, or what happens to a program that closes. The commit history is the only signal, and the sensible use of that history is watching it rather than auditing it.

If you want to run your own scraper instead, the generator repository is where you would look. If you just want today's scope list, you are already finished, because there is nothing to configure and no key to obtain. The only contact offered is a Signal handle, which is consistent with a project run by one person who does not want an issue queue.

Where this sits against the alternative workflows

It helps to be clear about what this repository replaces and what it does not.

For a researcher deciding where to spend an afternoon, the alternative is opening each platform's directory and reading program pages one at a time. That is slower and gives you a view of one platform, whereas a diff of domains.txt tells you what changed across all of them at once, which is how you spot a company that just expanded scope or quietly dropped it.

For automation, the alternative is a paid asset monitoring product or a commercial bug bounty data feed. This is free and MIT licensed, which makes it attractive as a starting signal and a poor thing to build a business on, since the data is someone else's scrape of someone else's platform and neither party has a contract with you.

One gap is worth naming. The Hackenproof data file appears in the README as a commented-out line, so it is documented but not published, even though hackenproof is listed among the repository topics. Treat the set of platforms as HackerOne, Bugcrowd, Intigriti, YesWeHack and Federacy, and check the data directory yourself if that distinction matters to you.

Editorial conclusion

This is a data repository that happens to be useful, not a project with an opinion. Its entire value is that someone runs a scraper on a schedule so that you do not have to, and then commits the result where anything can fetch it. The wildcard caveat in the README is the part most people miss and the part that keeps you out of legal trouble, because a wildcard in scope does not mean every subdomain beneath it is, and platforms publish explicit exclusions for exactly that case. For reconnaissance, subdomain enumeration and deciding where to spend an afternoon, domains.txt is the cheapest starting point on the public internet, and the raw JSON files are there when you want the program structure rather than a flattened list. For anything beyond reading, the generator lives in a separate bounty-targets repository, this repository has no issues open, and its contact details are a Signal handle rather than a tracker, so treat it as a feed to consume rather than a dependency to build on.

Frequently asked questions

Official sources

1. arkadiyt/bounty-targets-data on GitHub
2. Issues
3. License: MIT
4. README