I Built a Bug Bounty Recon Tool That Automates the Boring Parts (So I Don’t Have To)

If you've ever done bug bounty hunting, you know the drill: before you get to the actually interesting part — finding a real vulnerability — you spend a huge chunk of time on repetitive setup. Enumerate subdomains. Check which ones are alive. Scan ports. Run vulnerability templates. Dig through JS files for leaked endpoints. Rinse and repeat for every target in scope.

So I built a tool to automate all of it — code's on GitHub here: kushalbhattarai5/Bug-Bounty-Recon.

What it actually does

The pipeline chains together four well-known, open-source security tools — all from ProjectDiscovery — into one command:

subfinder → httpx → naabu → nuclei

subfinder → httpx → naabu → nuclei

1. subfinder passively enumerates every subdomain it can find for a target.
2. httpx probes that list and tells you which hosts are actually online right now.
3. naabu scans those live hosts for open ports beyond the obvious 80/443.
4. nuclei runs thousands of community-maintained templates against everything, checking for known CVEs and common misconfigurations.

At the end, a small Python script turns all of that raw output into one clean, readable report.md, grouped by severity, so I'm not digging through four separate text files after every scan.

I later added a fifth optional stage: crawling JS files with katana and regex-scanning them for leaked API keys, tokens, and internal endpoints — because a surprising number of real findings in bug bounty come from things developers accidentally leave in client-side JavaScript.

The important caveat

None of this finds new vulnerabilities. nuclei only flags things that match an existing template — known CVEs, common misconfig patterns, exposed panels. Everything it outputs is a lead, not a confirmed bug. The tool doesn't replace the actual skill of bug bounty hunting; it just clears away the repetitive setup so I can spend my time on the part that actually requires a human brain — verifying impact and deciding what's worth reporting.

I also built in a hard rule for myself: the script asks me to retype the target domain before every scan, as a forced pause to double check I'm actually authorized to test it. Scanning something without permission isn't a gray area — it's the fastest way to turn a hobby into a legal problem.

What actually broke (and what I learned)

A few things bit me while building this, and they're worth mentioning because they're the kind of thing that looks like a tool bug but is actually an environment quirk:

Two different tools named httpx. Kali Linux ships a Python package also called httpx — a general-purpose HTTP client library, completely unrelated to ProjectDiscovery's recon tool of the same name. Depending on PATH order, typing httpx could silently run the wrong one, and the error messages it throws (No such option: -l) don't make that obvious at all. The fix was to stop relying on PATH lookup entirely and resolve each tool by its explicit install path instead.

naabu doesn't want full URLs. Feeding it https://api.example.com instead of just api.example.com fails with a vague "no valid targets found" error. Small thing, easy to miss, wastes ten minutes the first time it happens.

nuclei -jsonl makes your terminal unreadable. I originally used -jsonl thinking it'd give me structured output to parse later — which it does, but it also forces raw JSON into the terminal instead of nuclei's normal colorized, human-readable findings. The fix: use -o for the readable output and the separate -je flag to export JSON on the side. Small flag, big quality-of-life difference.

None of these were hard problems once diagnosed, but each one was a reminder that "automate everything" pipelines are only as good as the friction you catch and smooth out along the way.

Where it's headed next

A few things still on the list:

• Severity-based notifications — a webhook that only pings me when something high or critical actually shows up, instead of me checking the terminal.
• Diffing between scans — surfacing only new findings on repeat scans of the same target, instead of re-reading everything each time.
• Noise filtering — auto-suppressing low-value template matches I've already learned aren't useful.

The goal isn't to make the tool "fully automated" in the sense of removing me from the loop entirely — verifying findings and deciding what's worth reporting will always need a human. The goal is just to stop spending my limited hunting time on setup, and spend it on the part that actually pays.