Reality Check: Bug Bounty Isn't Easy Money

Welcome to bug bounty, where you are unpaid, under-appreciated, and thought of as a nuisance. But damn, it can be fun, rewarding, and the best way to learn new techniques and put them into practice.

Let’s set the stage properly. If you’re expecting to launch Claude, tell it to hack the world, and drown in P1s, crits, and money…time for a reality check. That’s not happening. The rest of the world is doing the exact same thing, and there’s only so much low-hanging fruit to go around.

Meme by @0x_shaq

Finding vulnerabilities takes serious technical chops, a lot of time, some luck, and a solid understanding of impact. Yes, impact. You’re going to hear that word a lot.

If you’re still here and I didn’t scare you off, let’s get into it. Brand new? Start with my 2026 Bug Bounty Setup post first.

Things Nobody Puts in the Program Brief

Here are some of the harsh truths about bug bounty:

• Dupes: someone got there first, including issues the company already knew about internally. You get nothing.
  • Tough one. Sometimes companies or triagers get confused and think it’s a dupe. Get better at report writing. Sometimes it’s unavoidable.
  • Skip the low-hanging fruit or accept that 9 out of 10 times it’s going to be a dupe.
  • Find your edges. Don’t do the same thing as everyone else.
• Slow payouts
  • Your initial report wasn’t clear enough? Say hello to another 1-2 weeks to get to the next stage.
  • Submitted a low severity finding? Say hello to months before you see any money (depends on the program, private vs public).
  • Low reputation (your standing on the platform)? It’s going to take longer to get seen.
• Downgrades (more on this below)
  • 60-70% of my submissions get downgraded.
  • You have to be willing to go to bat for them.
• By-the-book rarely reaches critical (more on this below)
• Bad reports cost you money
  • Your bug gets confused with existing findings.
  • The impact isn’t properly conveyed.

Shoutout to Jason Haddix who talks about some of the harsh realities of bug bounty: Dark Side of Bug Bounty

Sweet Pentest Child

If you come from a pentest background, switching to bug bounty can be a bit jarring. You know that stack trace you’d report to a client? Yeah, in bug bounty that’s what we call informational. Internal hostnames? Informational. Debugging information? Informational.

Internally, you are the expert. You say something is a finding, it’s a finding. In bug bounty, someone else makes that call, and they’re going to ask one question: what can you actually do with it? You found a stack trace, great. Does it get you anywhere? If the answer starts with “well, theoretically…” it’s not a finding.

That was a hard adjustment for me. I came up as an internal pentester, and internal work trains you to find as many vulnerabilities as possible. Impact came second, especially early in my career. It didn’t help that internal services are usually easier to exploit, since companies put less security effort into things that don’t face the internet. Bug bounty targets are the opposite. They sit on the edge, the internet-facing side of the company, and they’re usually much more locked down.

Not everything gets thrown out, though. The technical knowledge and the drive to find issues carry over, and so do the communication skills, which matter more than you’d think once you’re writing reports. The biggest one for me is knowing how a company works on the inside. The same internal technologies show up at company after company, so when you do find a way in, you already know what to look for.

Fight For Your Bug

aka death by a thousand cuts

Sometimes you’re going to submit a critical, and for one reason or another it’s going to get downgraded. This is probably my least favorite part of bug bounty. You submit a 100% valid critical, you can barely sleep because you’re so excited, and you wake up to see the first thing they did was knock it down to a P2 or P3 for some arbitrary reason. It’s soul crushing.

A lesser-known skill in bug bounty is being willing to go to bat for your vulnerability. Something like 60-70% of my submissions get downgraded at some point, so you’d better get comfortable pushing back.

Here’s one that went all the way.

I found an endpoint on a large company that acted like a proxy. Give it any URL, over GET or POST, and it would fetch it and hand you back the full response. That’s server-side request forgery (SSRF), and the full-response kind is the bad kind. You’re not guessing whether your request landed, you’re reading whatever comes back. In this case, what came back was their internal network.

I submitted it as a critical. I showed I could reach an internal service, and then I stopped, because I thought that’s what you’re supposed to do. I thought the steps to reproduce were clear: go to the site, anything appended to the endpoint gets fetched, and set up a Burp Match and Replace rule so you can browse the internal service easily. I included screenshots of the configuration.

Eleven days later, the triager replied that they couldn’t reproduce it. Attached was a screenshot of them reproducing it.

They just didn’t know what they were looking at. So I rewrote the steps, slower and more deliberate, walking through Match and Replace one step at a time. That got them there. They changed the category (Bugcrowd’s Vulnerability Rating Taxonomy, or VRT) from SSRF to Server Security Misconfiguration > Web Application Firewall (WAF) Bypass > Direct Server Access, and rated it P4.

For context, Bugcrowd rates findings from P1 (critical) down to P5 (informational), so P4 is low. The category change matters too. The category a bug is filed under sets its baseline severity, so reclassify it and the severity drops with it. That reclassification isn’t just a label. It’s money. On this program, a P4 pays $50 to $125. A P1 starts at $1,750.

I pushed back:

Could you explain why the severity was lowered? This allows unauthenticated internal access to web resources. Due to the sensitivity and potential of impact this should be considered a critical vulnerability. Right now attackers have a portal into your network to access applications that don’t have as much security on them as externally facing ones. As seen with the [redacted] tools.

I stopped testing against internal resources due to impact and scope concerns but I’d be happy to continue searching the internal resources to further demonstrate impact.

Nothing. No reply.

So I went back and dug deeper. Behind that endpoint were internal forums and yum repos, and the yum repos had downloadable packages containing their source code. I documented all of it with a pile of screenshots, then pulled the only lever a hunter has: requesting remediation. Someone finally took a look and replied:

Based on the limited impact you demonstrated here we will adjust this to the P3 rating. Note that the final severity, and status of this submission are subject to change as this receives a further review from the team working on this program.

Limited impact. Source code. P3.

At that point I gave up and moved on. Two months later, the company itself got around to looking at it and marked it P1. It paid $1,750, which felt pretty low for everything it took to get there.

It worked out. Often it doesn’t. And at no point in those two months did I have any control over what happened to my report.

While I could look at this experience and blame the triagers or the program or the company, that doesn’t help me. Instead, there are actually lessons I can take away from this.

• Poor steps to reproduce led to friction. I assumed technical knowledge on the triager’s side, and that bit me.
• My first report didn’t show the full impact. I proved I could reach internal and stopped, and a P4 is what stopping gets you. More on that next.
• I get to choose where I spend my time.

While it was a frustrating experience for me, the real loss here is on the company’s end, because I won’t be putting my time into their program again. That’s the power we have as hunters. The choice of where to put our energy. Bugcrowd and HackerOne only work because countless skilled security researchers are willing to show up.

Impact, Impact, Impact (Terms and Conditions Apply)

Putting it bluntly, following ToS to the letter will often prevent you from proving out impact and reaching criticality. There it is, that’s the secret.

Refer to my finding above, I proved I could reach internal services and stopped. What was the cost? Impact. I stopped before proving that this was a call-your-engineer-at-3am bug. By the book, or at least the book in my head, you reach internal and you STOP. This is not ideal for proving out impact.

What the program’s rules actually said: no customer data, no customer accounts, avoid negative impact, stop and ask if a test might be destructive. Nothing says “stop once you reach internal,” but I assumed it did. Read the rules you actually have, not the ones you assume, and when you hit the grey area, use your best judgment.

It always surprises me how many limits are imposed upon good-faith researchers. While writing this post I came across this article by Intigriti: Aggressive scanning in bug bounty (and how to avoid it). Aggressive scanning, that seems a bit… over the top. But let’s take this as an example. In it they mention a program that asks researchers to limit themselves to 5 requests per second (RPS). Okay, let’s go ahead and map that out.

One pass, no file extensions, no recursion, and one tool at a time. The limit is per program, not per tool or per host, so nothing runs in parallel. Add three extensions and every number quadruples. Good luck finding a needle in a haystack!

Slow is one thing. Some attack vectors need a lot of requests in a short window, and those get awkward to prove at all.

Take race conditions. Testing one means firing 20 to 30 requests at the exact same moment, like Burp’s single-packet attack. That burst breaks a 5 RPS limit outright, so you’re asking the program for permission before you can even test.

No shade at Intigriti, but it’s the same problem again. Stay strictly inside the rules and some impact gets a lot harder to prove.

My hard line is never to perform DoS, destructive testing, or anything that modifies customer data. These are risks I am never taking. If you need to test modifications, always create two accounts and use those for testing.

Now I am not saying go out there and ignore ToS and focus purely on findings. No. You need to find the balance between showing impact while maintaining good faith. This is a very difficult thing but let’s try to break it down a bit.

Your report should leave no doubts as to what the impact of exploitation is for both sides (researcher and business). This is where you run into the grey area. You find an Insecure Direct Object Reference (IDOR) that exposes PII. That is probably a high. Now say the same vulnerability exposes 10k+ customer records. That’s a critical. But if you can’t pull other customers’ data, how do you prove it? This is the conundrum. The answer: you still prove it out, but take no more than you need to clearly demonstrate the impact. Use two accounts you own, show the IDs are predictable, and if you have to touch a real record, take one and say so in the report.