Got My First $$ Bug Bounty 🎉

And honestly, it feels different when you see that first bounty land in your inbox. It may not have been a huge amount of money, but for me, it represented something much bigger — proof that I could actually find and responsibly disclose a real-world security vulnerability.

So, here's the story of how I found it.

I Didn't Start With HackerOne or Bugcrowd

When I started bug hunting, I obviously knew about platforms like HackerOne, Bugcrowd, and YesWeHack.

But I deliberately didn't focus on the public programs listed there.

Why?

Because many of those programs have a huge number of researchers hunting on them. I'm not saying competition is something to be afraid of — competition is simply part of the bug bounty journey.

But as a beginner, I wanted to explore a slightly different path.

My recommendation to other beginners would be:

Don't limit yourself to the popular public programs. Look for private programs and less-crowded targets as well.

One resource I found useful for discovering potential targets was the Bug Bounty Dorks repository.

Of course, always make sure that whatever you test is actually authorized for security testing.

Finding an Interesting Target

During my recon, I came across an interesting platform used for managing construction-related projects.

What immediately caught my attention wasn't necessarily the functionality itself.

It was the authorization model.

The platform allowed organizations to create multiple users with different roles and permission levels.

And whenever I see something like:

• Multiple users
• Multiple roles
• Organizations
• Different permission levels

One category immediately comes to mind:

Broken Access Control (BAC).

There are usually interesting things to investigate around authorization boundaries.

So I started exploring the application.

And eventually, I found something interesting.

Let's Spill the Tea ☕ — The Vulnerability

The vulnerability was actually present in the registration flow.

The application had implemented a mechanism called Proof of Work (PoW).

If you've never encountered PoW in an application before, the basic idea is fairly simple.

Before allowing an expensive or potentially abusive operation — in this case, account registration — the server asks the client to perform some computational work.

The goal is to make automated mass actions more expensive.

In this particular implementation, the registration flow used something called a "hello blob", which was a Base64-encoded value involved in the PoW mechanism.

The interesting part was that the same hello value could be reused.

In other words, the challenge wasn't properly tied to a single registration attempt.

What did that mean?

I could use the same PoW value while attempting to register multiple accounts with different email addresses.

The PoW was therefore not functioning as a truly single-use challenge.

I created a small script to verify the behavior and confirmed that the same challenge could be reused across multiple registration requests.

At that point, I had enough evidence to report the vulnerability.

There Was Also Rate Limiting

While testing, I noticed another important security control.

After approximately three requests, the application started rate-limiting the requests.

Initially, this looked like a good mitigation.

But the rate limit was based on the IP address.

So, in theory, an attacker could potentially attempt to bypass the restriction by rotating IP addresses.

However, I didn't attempt to bypass the rate limit.

Why?

Because I already had enough evidence to demonstrate that the underlying PoW implementation could be reused.

There was no reason to generate unnecessary traffic or push the testing further.

This is something I think beginners should learn early:

Once you have enough evidence to demonstrate a vulnerability, stop.

You don't need to prove every possible exploitation path.

Responsible disclosure also means knowing when to stop testing.

Reporting the Vulnerability

I documented the issue and submitted a report to the company.

I included:

• A clear explanation of the vulnerability
• Steps to reproduce
• Screenshots
• A proof-of-concept script
• The security impact
• Details about the rate-limiting behavior

Then I waited.

And waited.

And waited.

Two Weeks With No Response

For around two weeks, I didn't receive a response.

Eventually, I started losing interest in hunting on the platform.

So I sent them a follow-up email asking them to review the report and, importantly, asking whether they could reproduce the issue on their side.

After that…

I completely forgot about it.

I moved on to other things and continued learning and hunting.

And Then I Got The Email…

In the second week of August, I suddenly received an email from the company.

They had validated the vulnerability.

Not only that, they had assigned it a CVSS score of 5.3 and informed me that they were willing to reward me with a bounty.

And that was the moment.

My first bug bounty. 🎉

The amount wasn't huge.

But honestly?

I didn't care.

It was my first accepted vulnerability and my first bounty.

I would have accepted whatever came my way at that point. 😂

Because the money wasn't the most important part.

The important part was knowing:

I found a real security issue in a real application, reported it responsibly, and the company fixed it.

That was incredibly motivating.

What Happened After the Report?

The company subsequently changed the registration flow so that the PoW challenge could no longer simply be reused.

The updated implementation included:

• Making the PoW challenge single-use
• Adding a 30-second expiration
• Strengthening rate limiting on the registration endpoint

That was also one of the most satisfying parts of the experience.

The vulnerability wasn't just theoretical.

It resulted in an actual security improvement to the application.

The Biggest Lesson: Consistency

If there's one thing I learned from this experience, it's this:

Consistency matters more than you think.

You might spend days hunting and find nothing.

You might submit reports and get rejected.

You might find something that looks interesting but turns out to be invalid.

You might even report a valid vulnerability and receive no response for weeks.

That's all part of bug bounty hunting.

The important thing is to keep learning, keep testing, and keep reporting responsibly.

You don't need to find a critical vulnerability on your first day.

You just need to keep improving.

Eventually, you might find yourself writing an article like this one.

A Few Tips For Beginners

1. Don't Only Hunt The Most Popular Programs

Popular programs attract a massive number of researchers.

That's not necessarily bad, but as a beginner, exploring less-crowded and legitimately authorized programs can give you more opportunities to learn.

Don't blindly chase the same targets everyone else is hunting.

2. Learn To Think About Attack Surfaces

Don't just run tools and wait for vulnerabilities to appear.

When you see functionality such as:

• Registration
• Login
• Password reset
• Organizations
• User roles
• File uploads
• APIs
• Invitations
• Sharing
• Payment functionality

ask yourself:

"What could go wrong here?"

That's where the interesting bugs often begin.

3. Use AI As A Learning Assistant

AI can be extremely useful when you're stuck.

You can ask questions like:

"What security issues should I investigate in a registration flow that uses Proof of Work?"

or:

"What attack surfaces should I consider when an application has multiple organizations and role-based permissions?"

Don't blindly follow the answers.

Use AI to generate ideas, understand concepts, and explore attack surfaces, then validate everything yourself.

4. Follow Experienced Bug Hunters

Twitter/X and LinkedIn have a huge community of security researchers.

Follow researchers who share:

• Write-ups
• Methodologies
• Recon techniques
• Interesting vulnerabilities
• Lessons from rejected reports
• Responsible disclosure stories

You can learn a lot simply by seeing how experienced hunters approach a target.

I'll also leave my own Twitter/X and LinkedIn profiles below if you'd like to follow my journey.

And I'd recommend exploring the people I follow as well. There is a lot of knowledge hidden in this community.

Final Thoughts

My first bounty wasn't a critical RCE.

It wasn't a million-dollar bug.

It wasn't even a particularly complicated vulnerability.

It was a relatively simple implementation flaw.

But it taught me something much more valuable:

You don't need to be an expert to start.

You need curiosity.

You need patience.

You need to keep learning.

And most importantly…

Keep Hunting. 🔥

Start small.

Find something.

Report it responsibly.

Learn from the response.

Then do it again.

Someday, you might be the one writing about your first bounty.

And trust me…

That email hits differently. 🥹💰

Happy Hunting! 🐛🔎