Wondering what bash scripting for bug bounty actually looks like once you get past the theory? There’s a specific moment every bug hunter remembers: the first time they checked a subdomain by hand, then had to check another one, then another, then twenty more after that. Somewhere around subdomain number fifteen, a quiet thought shows up: there has to be a faster way than this. There is, and it takes about ten lines of Bash.
Quick answer: Bash scripting for bug bounty means chaining commands you already know, like curl and grep, into a reusable script. A simple loop, for example, can check a whole list of subdomains automatically instead of one at a time.
There is, and that’s exactly what bash scripting for bug bounty work looks like in practice. It doesn’t require becoming a professional programmer, just about ten lines of Bash.
Bash scripting for bug bounty: why Bash, specifically
Bash is the language your terminal already speaks. Every command you’ve typed so far (grep, curl, find) is something Bash understands natively. Scripting in Bash isn’t learning a new skill from scratch. It’s just writing down a sequence of commands you already know, so the computer can run them for you instead of you typing them one at a time.
That’s the whole reframe: a Bash script isn’t “real programming” in the intimidating sense. It’s a to-do list your terminal can execute on its own.
Quick tip
Save any script you write with a .sh ending, like recon.sh. It’s not strictly required, but it instantly signals to you, and anyone reading over your shoulder, exactly what the file is for.
Your first script: checking if a subdomain is alive
Let’s build something real instead of a toy example. Say you’ve got a list of subdomains and you want to know which ones actually respond. Doing that by hand means opening each one in a browser, one at a time, and hoping you don’t lose count.
Here’s the whole script:
#!/bin/bash
while read domain; do
curl -s -o /dev/null -w "%{http_code} $domainn" "https://$domain"
done < subdomains.txtThat’s it. Four real lines of logic. It reads your list of subdomains one at a time, quietly asks each one for a response, and prints back the status code next to the domain name.
Quick trick
Run chmod +x recon.sh once after saving the file. That single command gives your script permission to actually run. Skip it, and Bash will refuse to execute the file at all.
Breaking down what’s actually happening
The while read domain; do ... done < subdomains.txt part is a loop. It just means “do the following, once for every line in this file.” Nothing more mysterious than that.
Inside the loop, curl does the actual work: it quietly requests each subdomain and captures the response code instead of dumping the whole page to your screen. The -s keeps things quiet, and -w controls exactly what gets printed back to you.
Change nothing else, and this same four-line pattern works for checking a hundred subdomains just as easily as it works for checking three.
Quick tip
Test your script on a tiny file first: three or four domains you already know are alive. Confirming it works on a small, predictable list before pointing it at a hundred unknowns will save you a lot of confused debugging later.
Making it actually useful: saving results to a file
Right now, results just fly past on your screen and disappear. A small addition fixes that:
#!/bin/bash
while read domain; do
curl -s -o /dev/null -w "%{http_code} $domainn" "https://$domain"
done < subdomains.txt >> results.txtThat single >> results.txt at the end quietly redirects everything the script prints into a file instead of your screen, appending each run instead of overwriting the last one. Now you’ve got a growing, searchable record of every scan you’ve ever run.
Quick trick
Once results are saved to a file, pipe them into grep "200" to instantly filter down to just the subdomains that responded successfully. Your two skills (Bash scripting and the commands from the earlier posts) start reinforcing each other here.
Frequently Asked Questions
Do I need programming experience to write Bash scripts for bug bounty?
No. A useful first script can be just a handful of lines using commands you already know from the terminal.
What is the simplest bug bounty automation script?
A loop that reads a list of subdomains from a file and checks each one with curl, saving results to a file.
Why automate recon instead of doing it by hand?
Automation lets you check hundreds of targets in the time it takes to check one by hand, and it runs unattended while you do something else.
What’s the difference between Bash and Python for bug bounty automation?
Bash is best for quickly chaining existing commands together; Python is better once you need to parse structured data like JSON or make more complex decisions.
You just automated your first real recon task
Look at what actually happened: you took a task that used to mean manually checking domains one by one, and turned it into something that runs unattended while you do literally anything else. That’s the entire promise of automation, and you got there in under fifteen lines of Bash.
That’s bash scripting for bug bounty in miniature. This script is intentionally simple, and that’s the point. Real recon workflows are just this same idea, chained together and scaled up. Master this pattern, and the more advanced scripts you’ll write later will feel like small variations on something you already understand, not brand new mountains to climb. When you’re ready to handle messier data, Python for Bug Bounty: Write Your First Recon Script picks up right where this leaves off.