My First Bug Bounty Paid Nothing

Hello, I am Nitin.

My first accepted bug bounty report paid me nothing.

Not rejected. Not a duplicate. Accepted, triaged, confirmed as a real issue by a real security team, closed as Informative. Zero dollars.

I was furious for about a week. Then I understood what had happened, and it reshaped how I hunt more than any technique I have learned since.

The bug

It was a session management issue. The kind that has its own weakness classification and appears in every checklist you will ever read.

The short version: the application was not properly invalidating existing sessions when it should have. A session that ought to have been destroyed was still being honoured by the server afterwards.

I was thrilled. I had found a real flaw in a real company's production application, by hand, by noticing something inconsistent and pulling on it. I wrote it up carefully. I included the steps. I explained the weakness, referenced the classification, and described the risk in general terms.

And the risk was where I lost.

Why it paid nothing

Here is what my report actually communicated, once I learned to read it the way a triager does.

I had proved that a session token survived an event that should have killed it. I had not proved that this let anyone do anything they could not already do.

Every exploitation path in my write-up began with an assumption. If an attacker had obtained the token. If the user had been on a shared machine. If someone had already captured the session. Each "if" was doing enormous work, and none of them were demonstrated.

A security team triaging a hundred reports a month does not assign severity to "this is bad practice." They assign it to "here is what an attacker achieves, from this starting position, with these prerequisites." My report had the first half of a finding and the wrong half.

The classification I proudly cited was a description of the weakness. It was not an argument about impact. I had submitted a definition and expected to be paid for a consequence.

What the fix looks like

The same underlying flaw can be worth nothing or a great deal, and the difference is entirely in what you attach to it.

To turn that class of issue into something a program pays for, you have to close the gap between the weakness and a real outcome. That means answering, concretely: what is the realistic way an attacker starts here, what do they gain, and can I demonstrate it rather than assert it.

Sometimes the answer is that you cannot, and the finding is genuinely low value. That is a legitimate result. But very often the answer is that the weakness is a link in a chain, and the chain is the report. A session that outlives a password change is uninteresting on its own and becomes serious when combined with any mechanism that exposes tokens. Find both, show both, and you no longer have an Informative.

The lesson generalises to everything: programs do not buy vulnerabilities. They buy demonstrated consequences.

The money question, answered honestly

Since this is the money act of this series, let me give you the real numbers rather than the motivational ones.

The largest platform paid out around 81 million dollars across roughly 1,950 programmes in a recent twelve-month period, up about 13 percent year on year. That sounds enormous until you look at the distribution. The top 100 programmes accounted for 51 million of it. The top ten alone accounted for 21.6 million. Concentration on the researcher side is similar: the top 100 all-time earners have taken around 31.8 million between them.

Meanwhile the average annual payout across all active programmes was roughly 42,000 dollars. That is the whole programme, across every hunter who reported to it, for a year.

And the floor moves. One well-known open-source bounty programme recently cut its reward tiers dramatically, with a medium-severity payout dropping from over 1,800 dollars to under 300, and critical from over 9,000 to around 2,250. If your financial plan assumed those rates, your financial plan changed without your permission.

Realistic first-year expectations for a part-time beginner are in the region of a few hundred dollars a month, sometimes nothing for long stretches. Full-time viability typically arrives after one to two years of consistent work, and most people who reach it diversify into consulting, training or content rather than living purely on bounties. I did.

None of that is discouragement. It is the information I wish someone had given me before I built expectations out of screenshots of five-figure payouts.

What the zero-dollar report was actually worth

I can trace a straight line from that Informative to every paid finding I have had since.

It taught me to write the impact section first. Before I test, before I write a single line of the reproduction steps, I ask what the sentence is going to be. "An unauthenticated attacker can do X to Y." If I cannot complete that sentence with something specific, I do not have a report yet. I have an observation.

It taught me that the report is the product. Companies do not experience your testing. They experience your document. Two hunters can find the identical issue and receive very different outcomes based entirely on which one made the consequence legible to a busy triager.

And it taught me that Informative is a grade, not an insult. It means the finding is real and the argument is not. That is a fixable problem, and fixing it is the single highest-return skill in this field.

I still keep that first report. It is the most valuable zero I have ever earned.

Conclusion — steal this checklist

• Write the impact sentence before you test. "An attacker who is X can do Y to Z." If you cannot finish it, you do not have a report.
• Count your assumptions. Every "if the attacker already has" in your write-up reduces severity. Remove them or demonstrate them.
• Never submit a weakness classification as an argument. It describes the flaw, it does not establish consequence.
• Look for the chain. Low-value findings become serious when you connect them to something that supplies the missing precondition.
• Treat the report as the product. Clarity, reproducibility and a legible impact story decide your payout more than cleverness does.
• Read Informative as feedback, not rejection. The bug was real. The case was not made.
• Set expectations from the distribution, not the headlines. Payouts are heavily concentrated and reward tiers can be cut without notice.
• Plan to diversify. Almost nobody sustainable in this field lives on bounties alone.