October 13, 2026

From Hall of Fame to My First $250: How a VDP Hunter Finally Got Paid

I’ve been around security stuff since 2022. But for most of that time I was just curious, not skilled. And every time someone brought up…

By Subadevan C

5 min read

I've been around security stuff since 2022. But for most of that time I was just curious, not skilled. And every time someone brought up bug bounty, I'd think "nah, that's too hard, not for me" and move on.

Turns out I was wrong. It took me a while to find out, but I was wrong.

This is how I got my first paid bounty. It was $250. Not life-changing money, I know. But it was the first time someone paid me for a bug, and that changed something in my head.

What actually got me started

It wasn't a course. It wasn't some YouTube guru. It was the people around me.

My friends started getting Hall of Fame spots. Then even juniors I knew started getting them. HoF after HoF, showing up on my feed. And watching people right next to me do the thing I thought was impossible kind of broke the whole "it's too hard" excuse I'd been hiding behind.

So I just asked them. "How are you finding these? Show me." No ego about it. Then I copied exactly what they did. Same programs, same approach, same habits.

And it worked. I got 3 or 4 Hall of Fame acknowledgments, some on self-hosted VDPs, some on HackerOne VDP programs.

If you're new: a VDP usually pays you in recognition, not money. A thank you, your name on a Hall of Fame page. People sometimes look down on VDPs but honestly they're the perfect place to start. Low pressure, forgiving programs, and you learn how triage actually works without any money riding on it.

After about a month of collecting HoFs I stopped and thought, why am I only doing free programs? Why not try one that actually pays?

Then reality hit

So I picked a paid program. And it was hard. This one bug took me two full days of research.

Here's the part most people leave out of their writeups: I had no fancy tools. No paid scanners, no expensive recon subscriptions, nothing like that. What I had was a free AI coding assistant that was giving out a lot of credits back then. I used every single one.

That was my setup. A beginner's methodology and free AI credits. That's it.

Here's what I did, commands included.

Recon, the boring free way

Subdomain enumeration with subfinder:

subfinder -d example.com -all -silent -o subfinder.txt

Then crt.sh for certificate transparency subdomains. I piped it through jq, stripped the wildcards, and sorted:

curl -s "<https://crt.sh/?q=%25.example.com&output=json>" \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u > crtsh.txt

Merged both lists into one and removed duplicates:

cat subfinder.txt crtsh.txt | sort -u > all_subs.txt

Checked which hosts were actually alive with httpx:

httpx -l all_subs.txt -silent -o live.txt

Nothing clever. Just free tools.

Actually using the website

This part I think a lot of beginners skip. I didn't just run scanners and wait. I opened the sites and used them like a normal person would. Clicking around, Ctrl+Click to open stuff in new tabs, getting a feel for how everything worked.

While doing that I was watching for the easy classic bugs, reflected XSS and IDOR. Not because they're easy to find, they're usually taken. But looking for them makes you understand how the app moves data around.

Nothing showed up. But that browsing is never wasted. It builds the map in your head you need for the next step.

JS analysis, where it finally clicked

Around this time someone introduced me to JavaScript file analysis, and this is the part that changed everything.

Websites load huge amounts of JavaScript, and those files leak stuff. Hidden endpoints, parameter names, sometimes actual secrets that were never supposed to be public.

So here's what I did.

Crawled all the JS files with katana:

katana -list live.txt -jc -d 5 -silent \
  | grep -iE '\.js(\?|$)' \
  | sort -u > jsfiles.txt

Downloaded all of them at once with wget:

mkdir -p js
wget -q -i jsfiles.txt -P js/

If some URLs act up, a curl loop does the same thing and keeps cleaner names:

mkdir -p js
while read -r url; do
  fname=$(echo "$url" | sed 's#[^a-zA-Z0-9]#_#g')
  curl -s "$url" -o "js/${fname}.js"
done < jsfiles.txt

Then I fed the files to free AI models and just asked:

"Is there any secret path, API key, hidden endpoint, or sensitive information in these files?"

I also did a plain grep for the usual keywords so I wasn't blindly trusting the AI:

grep -risanE "api[_-]?key|token|secret|/api/|bearer|authorization" js/ | sort -u

I wasn't doing anything smart here. I was just persistent, and the AI could read thousands of lines way faster than me.

And it found something. A path I would have scrolled straight past on my own:

/api/live-preview-env

An endpoint that was handing environment variables to the browser. Environment variables belong on the server. Why could the frontend ask for them?

The find

I hit it the simplest way possible:

curl -s <https://company.example.com/api/live-preview-env>

No auth, no cookie, no session. And it gave me this:

{
  "CONTENTSTACK_API_KEY": "bltxxxxxxxxxxxxxxxx",
  "CONTENTSTACK_DELIVERY_TOKEN": "csxxxxxxxxxxxxxxxxxxxxxxxx"
}

A CMS API key and delivery token, in plaintext, served to anyone on the internet.

Now, from my VDP days I already knew one thing: finding a token is not a finding. A token that does nothing is just a random string. The real question is what an attacker can actually do with it.

Getting it to work

I had messed with this CMS's GraphQL API before and it had blocked me. I didn't know how to authenticate properly.

So I did the same thing that got me my HoFs. I asked. This time I asked the chatbot, "I have this API key and delivery token, what's the correct way to use them on this GraphQL endpoint?"

It told me the exact header the API wanted. I followed it and sent a harmless test query, just __typename, which only asks the API if it's alive without touching any real data:

curl -s -X POST \
  "https://graphql.<cms-vendor>.com/stacks/bltxxxxxxxxxxxxxxxx?environment=production" \
  -H "Content-Type: application/json" \
  -H "access_token: csxxxxxxxxxxxxxxxxxxxxxxxx" \
  -d '{"query":"query { __typename }"}'
{"data":{"__typename":"Query"}}
  1. Authenticated. From the open internet, with a token that was never meant to leave the server.

That 200 was the moment it stopped being "a string I found" and became "a credential that works."

I tried to make it bigger and it said no

I'll be honest here, because over-claiming is how beginners wreck their reputation.

Once I was in, I threw the usual GraphQL attacks at it. Batching attacks, the other known tricks. I was hoping to turn this into something critical.

None of it worked. The token was read-only and most of what it reached wasn't that sensitive. No account takeover, no PII, no RCE. Just read access to content infrastructure that shouldn't have been exposed.

So I had two options. Pump it up into something it wasn't, or report it honestly for what it actually was.

I reported it honestly. Showed the leak, showed that the token authenticated, and explained the real impact: anyone, with no login, could quietly enumerate the company's content and metadata. And the fact that the token came from a server-side /api/ route, instead of being a normal public key, meant this was an accident, not a design choice.

The result

It got triaged and confirmed. The endpoint was fixed soon after. They rated it low severity per their policy and paid it out.

$250. My first paid bounty.

What I took away from it

The money won't change your life, and that's not the point. Here's what actually stuck with me.

The "it's too hard, not for me" story was always just an excuse. What broke it wasn't talent, it was watching people near me do it and being willing to ask them how. Ask, copy, then make it yours.

VDPs are not a lesser path. Those few Hall of Fame reports taught me how triage thinks and how to write a clear report, all with no money on the line. By the time I tried a paid program the process already felt familiar. Only the payout was new.

You don't need expensive tools. My whole pipeline was subfinder, crt.sh, httpx, katana, browsing by hand, and free AI credits. The AI didn't find the bug for me. It read thousands of lines of JS faster than I could and pointed me at the one path worth a second look. I still had to do the thinking.

Read the JavaScript. My manual XSS and IDOR hunting found nothing. JS analysis found the whole thing. The frontend leaks the backend's secrets all the time, so go read them.

And report what's real, not what you wish you found. I wanted this to be critical. I tried hard to escalate it and failed. Reporting it honestly got me a confirmed, resolved report and a clean record. Faking the impact would have gotten me an N/A and a bad reputation.

If you're where I was, into security for years but convinced bounties aren't for you, here's the short version. The jump from Hall of Fame to your first payout is smaller than it looks, and it starts the moment you stop reading and start asking.

Two days, free tools, one honest report, $250.

Now your turn

Tags: Bug Bounty, Cybersecurity, Infosec, Ethical Hacking, Beginners