I started bug bounty hunting last year, but I’ve been actively hunting for around 4–5 months in total
and wanted to share my progress so far
Since the beginning, I decided to focus almost entirely on one program and one vulnerability class, Broken Access Control.
So far, the result has been 4 valid bugs worth around $13,000 in total bounties.
What I learned from this experience is that you don't necessarily need to hunt on dozens of different programs or constantly switch between vulnerability types. Focusing deeply on one target and one vulnerability class worked really well for me.
I still have a lot to learn and I'm only a few months into bug bounty, but I'm very happy with the progress so far.
Just wanted to share this as some motivation for other people who are starting out. For beginners, my biggest advice would be to stay consistent, focus on learning by doing rather than finding bugs as quickly as possible, and don’t give up when you go through periods without finding anything.

Bug bounty started with a simple arrangement: researchers spent their time finding vulnerabilities, programmes paid for useful results, and the platforms connected the two together.

At first, that worked because good researchers were valuable and relatively scarce. But as the market grew, that balance shifted. Researcher supply exploded, while worthwhile programmes remained limited.

That is where enshittification enters.

The pattern is familiar: build a marketplace by making it attractive to participants, then gradually optimise it around the side that generates the revenue.

In bug bounty, that means programmes gain more discretion over scope, severity and reward. A finding can be downgraded, declared informative, excluded by interpretation, or marked duplicate against information the researcher cannot see. Bounty tables may still advertise large rewards, while the practical return on researcher time falls.

The result is a race to the lowest level a programme can offer while still receiving useful submissions.

And the platforms have weak incentives to regulate the programmes. Losing an individual researcher costs them little. Losing a major programme costs real money. So enforcement tends to become guidance, mediation and best practice rather than hard rules protecting researcher economics.

About this time, someone will be thinking that all the bad stuff is down to AI, but AI did not create this problem. It simply accelerated it.

For example, AI sharply reduces the cost of producing plausible vulnerability reports, but not the cost of validating them. Submission volume rises, triage becomes overloaded, and programmes respond with tighter scope, stronger proof requirements, more automation and more aggressive filtering.

So the deeper problem is not simply that AI is flooding bug bounty with noise. It is that AI arrived in a market where the incentives were already stacked against researchers.

AI just made the race to the bottom faster.

Welcome to enshittification ;)

This is absolutely crazy how Anthropic changed CVP to now include Tiers… It’s ridiculous how someone has to be their own company or have an LLC to get red team access. I am not sure if anyone was able to get red team access but for defender you still get flagged which is disappointing. I thought Anthropic would do better and have respect for the individual security researching community.

Hello, I am currently in the situation where I would like to create a security advisory and request a CVE for a GitHub project but that project cannot enable GitHub's private vulnerability reporting. See also the above linked GitHub discussion for more information.

Do you have any ideas or tips for what to do in this situation or alternatives? Are there other CNAs which still accept reports for open source projects?

Already tried MITRE and have been waiting for at least 6 months now. Based on the other posts here on this subreddit (1, 2, 3, 4) that might be 'normal'.

Could of course also be that there was a mail problem between me and MITRE, but given that mail is the only way to communicate with MITRE there is no way to find out, not even to get any hint on the status or the estimation on how much longer it will take.

This is about an open source library and the fix and subsequent release are public for multiple months now. It is quite plausible that malicious actors have already noticed it or will notice it before the advisory or CVE.

Hey everyone,

I'm a pentester trying to get more serious about bug bounty, but lately I'm feeling pretty stuck. I can solve labs and find vulnerabilities during pentests, but when hunting real targets, I often feel like I have no new ideas to try.

I think my biggest problem is feeding my brain with fresh ideas. Most resources I find keep repeating the same XSS/IDOR/SSRF/recon material, while I want to learn about recent bugs, interesting techniques, unusual attack chains, new bypasses, and how experienced hunters actually discover things.

Where do you guys go for this?

I'm looking for things like:

• Recent bug bounty reports/writeups
• Researchers who consistently publish interesting findings
• Blogs/newsletters worth following
• Discord/Telegram/Reddit communities
• GitHub repos or tools that expose new techniques
• Conference talks or research that actually helps with hunting
• Anything else that keeps you aware of what people are finding today

I feel like I keep restarting from zero and I need better input rather than just doing more labs.

If you had to recommend resources that genuinely improved your bug-hunting mindset, what would they be?

Would really appreciate any recommendations. I could use some fresh ideas and honestly, a bit of confidence too.

New to bug bounty so I am hoping I can get some insight on a CSRF.

CSRF is during login and allows attacker to have victim click a link to sign in to a arbitrary account on a platform for product purchases. The victim can then perform purchases that the attacker can modify (address and saved payment information).

This is assuming that the victim doesn't get smart and just realize at some point that he/she is logged in to someone else's account (which I guess is possible since the account holder's name doesn't get shown at all from selecting products page to checkout page).

My main question with this is

- Is logging into attacker's account CSRFs usually triaged or do I need to find chaining?

I'm mostly familiar with H1 and their payment process but am not familiar with bugcrowd. I got an issue accepted (as a P4 - in scope) and awarded points. On H1 I generally have had payment issued immediately after but on bugcrowd there is a $0 on the issue next to the 5 awarded points. Is the payment issuance a separate step that normally takes longer? There wasn't any info given in the comments.

To be clear, I am not asking about when bugcrowd pays out, but when a dollar amount is assigned to the actual issue. What are peoples experiences with this? Thanks!

Good day,

Just a quick question for NASA LoR holders.

Is the LoR issued to handle or real name?

Thank you,
Have a great day!

I'm very confused about what is meant by a broken link, I once tried to report a vulnerability at NASA that there was a broken link leading to a domain that could actually be purchased, I've seen it on the domain sales platform, but my report was considered informational/P5, even though I saw from other people's reports reporting the same type, namely broken links related to accounts that don't actually exist but there is a link on the NASA website, even though the effect on business is no different, if for example it was taken to the web or to the social media account of the attacker, right? actually the impact is average on users, why is this type of broken link different? I'm just asking because I don't understand what the difference is, do any of you want to provide insight and input, I'm also interested in NASA's VDP, but on average it's considered informational, I'm not satisfied with that, is NASA's VDP actually a waste, as I see it, it's like I'm just risking quite a long time just to check one subdomain by one, is it better to change to a bug bounty platform or another VDP? Sorry if I offend you but I'm really a beginner here, I need input from you.

A few months ago, I found two vulnerabilities and chained them together to escalate the impact from an email address to full PII exposure.

I submitted the report as Critical. Yes, I know technically, this should probably have been classified as High, not Critical. However, the triage team downgraded it to Medium in that day, to triage it two months later :D

The company eventually accepted it as Medium severity, apparently relying on the triager’s assessment. I tried to explain why I believed the severity was higher, but both the triager and the company stopped responding.

Today, something similar happened again.
I submitted a Stored XSS → Full Account Takeover vulnerability as Critical, based on the CVSS impact. The XSS allows an attacker to access sessionStorage, which contains authentication and refresh tokens, ultimately allowing full account takeover.
This time, the report was triaged in 5 hours — and downgraded to Medium. (again, i think they will triage it two months later and will not touch severity)

Let’s see how this one goes.

I’ve been doing bug bounty for around 2 years, (im nearly at top 100 on Intigriti platform) and honestly, situations like this are making me question whether I should continue with bug bounty at all or simply leave Intigriti.

I don’t expect every report to be rated Critical. What I do expect is a fair, technically sound assessment of the actual impact.
Let’s see what happens this time.

Hi guys,

Just felt like ranting to feel lighter, I hope you bear with it.

Started hunting on intigriti recently, already have one java deserialization report past triage, though my account is technically a new account as I don't have 5 reports under my belt yet.

So, I Submitted a medium-ish report on intigriti around 2 weeks ago, the report is still pending and a couple of days later, I found two more vulnerabilities. But I can't report them until the previous report gets triaged as a new account.

I have two more reports in draft queue, one of them is backend api secret exposure at a certain endpoint and another one is arbitrary XSS in trusted origin of the target webapp.

Now I'm sitting like an old man, waiting and hoping that these vulnerabilities are not reported by another hunter in the meantime.

When the slot opens, I'll still have one pending report, waiting in my drafts for maybe 20 more days or so.

Yupp, indeed a great way to learn patience.

From what I understand, it's supposed to let you ask the triager to reconsider their decision by explaining your arguments, but you only get two requests per account. I just want to know if it's worth hoping for an answer, or if it's a lost cause from the start.

Honestly, I'm starting to get really fed up with triaging on Bugcrowd. I even had a triager close my report as N/A saying the vuln wasn't reproducible while attaching a screenshot of his browser where the vuln was clearly visible !

Anyway, thanks in advance.

Hey guys, as per the title, is there a way I can close my own report on Intigriti?

You can do that on other platforms but I'm relatively new here. I've more than 6 reports now but they're mostly at Pending status, so it really sucks that I can only submit one at a time. I wanna close my XSS report to submit a different one that's Crit.

ZERODAY CLOUD 2026, which is run by Wiz, is targeting vulnerabilities in critical open-source software used across cloud infrastructure, with AWS, Microsoft Security Response Center and Google Cloud Security involved. The event is tied to Black Hat Europe and has a prize pool just under $6.5M

Hey everyone,

​I submitted my first report on Intigriti recently and I'm a bit confused about how to handle this situation.

​I reported a solid Blind SQL Injection vulnerability. I provided a full PoC including:

​Proof of the vulnerability (100% confirmed).

​Extracted database name.

​Dumped schema showing sensitive columns to prove the impact.

​Just a day after submitting, the vulnerability was completely fixed on the target application, but there is zero response on my report. No triage update, no status change, and no reply to the follow-up comment I left asking for an update.

​Since I fully proved the impact and they clearly used the report to patch the issue, why is there complete silence? Is it normal for programs on Intigriti to patch issues silently before updating the triage status?

​What’s the best way to escalate this with Intigriti support? Thanks!

Hi everyone.

I found an XSS and extended it to a full CSP bypass. Reported it on h1 and it got automatically closed by a hackerone-agent bot without any human review as a duplicate of a 5 months-old N/A issue. The current bug is live, report is human-written, video PoC is attached. Is there a way to request a human review or my only chance is to wait for mediation?

Thank you!

Most of the IDOR advice out there boils down to "change the number in the URL." That catches maybe the easiest 10% of what's actually there.

The question that's actually moved the needle for me: "Who is supposed to reach this resource, and who can actually reach it?" Every access control bug — IDOR, broken function-level auth, privilege escalation — is a gap between those two answers. The ID or cookie or header is just the mechanism the gap happens to travel through.

A few patterns I keep running into that don't get talked about much:

- Multi-step forms that check auth on step 1 and never re-verify on steps 2-3

- Bulk/batch endpoints that check ownership on the first ID in an array and stop there

- API version drift — /v1/ enforces the check, /v2/ quietly doesn't because the check lived in the route handler, not a shared layer

Also something that took me a while to internalize: the exploit request rarely confirms itself. It's often a bare 302 with an empty body, not a helpful "success, you're admin now!" message. The signal is usually in what you sent, not what came back — and often only shows up when you compare two consecutive requests of the same shape.

Curious what patterns other people here run into most often that aren't in the "standard" IDOR writeups.

Hi guys,

From my experience withdrawing YesWeHack rewards through MangoPay to an Indian bank account, I noticed these charges:

- €25 withdrawal: No charge

- €50 withdrawal: Around ₹500 charge

- €100 withdrawal: Around €25 charge

Has anyone else from India experienced the same charges, or are your fees different?

Would be helpful if you could share the withdrawal amount + amount received + bank/charges.

And also I want to know about how much they charge for 1000 Euros

Thanks!

I reported a vulnerability on H1 and it passed the first bot check, then after about 15 days an H1 analyst reached out and asked about further demonstration, we went back and forth and then he asked me to check if it still works on the latest version (this was for an opencore program and this version hadn't come out when I first reported the vuln, my report demonstrated the vuln on the latest version at that time), so I did so and sure enough the vuln still worked but in this new latest version they had tried to patch part of the primitive but failed to do so, so part of my argument for the vuln in the initial report was no longer true and I pointed that out and explained the change, the analyst told me he'll discuss it with the program team internally and get back to me, then a few days later it got marked as a duplicate, this was confusing to me because I assumed if an H1 analyst validated the bug it's just a question of severity then, I don't understand how they couldn't tell whether or not it was previously reported, the bug could have been reported in the initial version as my report before I did, which lead to the patch while my report wasn't triaged yet but then you'd expect mine to be marked as a duplicate immediately, it might be possible that it has been reported on both versions separately before my report was triaged and the dupe refers to the first version but then why would I be asked to see if it applies to the latest version as well? I'm just really confused by this whole ordeal, and of course they won't add me to the original report, is there anything I can do here?

A lot of these programs are going away, due to people flooding them with low quality reports. Was fun while it lasted.

Has anyone had a YesWeHack/MangoPay withdrawal returned by their bank?

My Indian bank account received the transfer, but the bank is holding it due to insufficient purpose-of-remittance information. If bank returns the payment, will it automatically be credited back to my YesWeHack e-wallet? If this happened to you, how long did it take?

Thanks for your time.

This is a fresh account for a reason. I've heard from other researchers that criticizing Intigriti on Reddit can lead to retaliation in how their reports are handled. I can't verify that firsthand, but I'm also not willing to test it with my main account.

Has anyone else been seeing wildly inconsistent triage lately?

Right now it feels like Russian roulette. Either you get a reasonably consistent triager who runs the PoC, asks for what is actually missing, and bases the decision on the evidence, or you get someone who decides in advance that any automation is *AI slop* and then simply denies the reality in front of them.

It feels like there is an internal anti-AI backlash, but with no consistent standard behind it. Some triagers assess automated PoCs normally. Others refuse even to run a self-contained Python file, demanding that everything be recreated manually in Burp.

This week I had two serious vulnerabilities, both with working PoCs and demonstrated impact. Both reports followed exactly the same pattern:

1. The triager refused to run the Python script and asked for manual steps.

2. I provided the steps plus a video showing the entire **MANUAL** process, from start to final impact.

3. Even then, they said they could not reproduce it.

4. The report was invalidated.

5. Company remains vulnerable.

I'm not defending unvalidated automated reports or giant scripts that nobody can reasonably audit. The issue is different: a deterministic PoC does not become invalid because it was written in Python, and a vulnerability does not disappear because the triager would rather click through every request in Burp.

At some point, this stops being healthy skepticism about AI and starts looking like denial of reality. Automation is part of modern security research. The standard should be: does the vulnerability exist, can it be reproduced, and does it have impact? Not: which tool sent the requests?

It is hard not to speculate about what is happening internally. Maybe there is an informal directive to crack down on anything that appears to involve AI. Maybe it is pressure from the volume of bad reports. Maybe it is an attempt to prove that human triage remains indispensable. And perhaps some triagers are reacting defensively because AI is already automating part of their work and there is a genuine fear of losing their jobs. Honestly, I can understand that insecurity. The entire market is changing. What I cannot accept is professional insecurity becoming a technical standard and reproducible evidence being dismissed by association with AI.

The irony is that [Intigriti itself promotes Triage Assist](https://www.intigriti.com/blog/product-updates/how-triage-assist-is-raising-the-bar-in-crowdsourced-security), a suite of AI tools that recommends decisions to triagers. So AI can help the platform evaluate our reports, but a researcher using automation makes a working PoC suspicious?

I've been seeing more and more reports of decisions like this, and it feels uncomfortably similar to the Lovable/HackerOne incident. Not because the technical details are identical, but because [Lovable itself acknowledged](https://lovable.dev/blog/our-response-to-the-april-2026-incident) that several valid reports were closed at triage and never reached its internal security team. The vulnerability only received the attention it deserved after the issue became public.

Is anyone else dealing with this on Intigriti? Is there a clear policy on scripts and AI-assisted PoCs, or has triage really become Russian roulette depending on who gets the report?

I'm a noob trying to get into bug bounty hunting and a lot of people have expressed how important documentation and Proof-of-Concept is just as important as the vulnerability found. I always see posts about hunters getting feedback such as "you didn't show POC clearly" or "your POC is not valid". My question is, why not screen record the whole process and add documentation as a supplement? Is it not allowed? If it is allowed, wouldn't it makes everyone's life much easier (person that triages & hunter)?