I'm getting pretty fucking tired of how HackerOne and Bugcrowd handle researchers, especially newcomers.

And no, I'm not complaining because I expect every report to be accepted or rewarded. I know duplicates happen, I know false positives exist, and I know not every bug has a security impact.

But there's a difference between rejecting a report for legitimate technical reasons and having a system full of contradictory decisions, unresolved issues, and increasingly restrictive rules for researchers.

Let's start with HackerOne.

You spend days auditing code, reverse engineering, building PoCs, and documenting a vulnerability, only to find out it's a duplicate of something reported ages ago.

Fine, somebody got there first.

But what really pisses me off is discovering how many old findings are apparently still unresolved, or cases where a fix appears to have been implemented but the report hasn't reached a proper final state.

Why is managing these issues apparently so difficult?

How many researchers are independently rediscovering the same old vulnerabilities because they're still present in the software?

And when you challenge a decision or request reconsideration, there's often no meaningful way to get the technical arguments reassessed.

That's not just frustrating. It makes the entire process feel opaque.

And Bugcrowd isn't any better when it comes to consistency.

Here's something that happened to me.

I submitted a vulnerability based on static analysis and reverse engineering.

The triager rejected it as a false positive because I hadn't demonstrated the impact with a working PoC.

Fair enough.

They specifically instructed me to submit a new report with reproducible evidence.

So I did exactly that.

I developed a working PoC, tested it on actual hardware, demonstrated the privileged operation, and independently verified the result.

I submitted the new report with all the evidence.

They marked it as a duplicate of MY OWN PREVIOUS REPORT.

The same one they had rejected as a false positive.

And the rejection message actually said another researcher had already reported the issue.

BOTH REPORTS WERE MINE.

What the actual fuck?

I'm not saying the vulnerability automatically deserves a bounty. I'm saying that if you explicitly instruct someone to submit a new report with additional evidence, rejecting it as a duplicate of the report you told them to replace is a ridiculous way to handle the situation.

In another case, a triager dismissed an operation that caused a verified physical device reboot as a "no-op."

I understand that a reboot doesn't automatically establish sufficient security impact, especially under specific device conditions.

But that's exactly the point: explain the actual technical reasoning instead of giving responses that don't properly address the evidence.

And now let's talk about newcomers.

Both platforms have quality-control mechanisms, but HackerOne's recent changes to trial reports are a perfect example of what bothers me.

Researchers who don't meet certain signal requirements have a limited number of trial submissions, and replenishment depends on report outcomes.

I understand why platforms want to reduce garbage submissions.

Nobody wants to deal with people mass-submitting unverified findings.

But why does the solution always involve putting more obstacles in front of researchers who haven't established a reputation yet?

You need valid reports to build your reputation.

But your submissions are restricted because you don't have that reputation.

You find a real vulnerability? Ancient duplicate.

You submit something that requires a technical disagreement to be resolved? Good luck getting a meaningful reconsideration.

Meanwhile, those outcomes can affect your ability to keep participating.

It's a fucking vicious circle.

I'm not asking platforms to accept bad reports.

I'm asking why quality control can't be accompanied by better onboarding, more useful feedback, consistent triage standards, and some actual accountability for decisions.

Researchers are expected to follow every rule, provide reproducible evidence, demonstrate impact, write professional reports, and accept every final decision.

Fine.

But shouldn't the platforms and their participating programs be expected to maintain equally professional standards?

Why is the burden of quality and accountability so heavily concentrated on researchers?

We're doing this research with our own time, equipment, and resources, often with no guarantee of getting anything in return.

We accept that risk.

What bothers me is seeing new restrictions introduced while fundamental problems with report handling, duplicate management, and technical review remain.

And let's be clear: I'm not claiming all triagers are bad. I'm sure plenty do excellent work.

But the inconsistent experiences are real, and researchers should be able to criticize them without being dismissed as people who are simply angry about not receiving a bounty.

I genuinely enjoy vulnerability research. Auditing software, reverse engineering, understanding security boundaries, and developing exploits are things I want to keep doing.

What I'm starting to dislike is dealing with the platforms themselves.

HackerOne and Bugcrowd need to improve their own processes before constantly making participation more difficult for newcomers.

Better handling of existing vulnerabilities. Better technical explanations. More consistent decisions. More transparent appeal processes. And a realistic path for new researchers to establish themselves.

Is that really too much to ask?

I'm interested in hearing from other independent researchers, especially people who started recently.

Have you encountered similar contradictions in triage, problems with old duplicates, or barriers that make it unnecessarily difficult to build a reputation?

What would you actually change about these platforms?

I submitted a security report to TRON DAO through HackerOne on September 23, 2026. After analyzing the code, I provided technical evidence, including a reproduction and a control case. I'm not going to share the PoC or details that could expose the suspected vulnerability.

On October 15, TRON DAO closed the report as “Not Applicable.” However, their response stated that the report was a duplicate and therefore not a valid issue. No technical explanation was provided, and they didn't identify the alleged duplicate.

So what exactly happened here? If the behavior isn't a security issue, why call it a duplicate? And if it is a duplicate, why provide no meaningful clarification? I spent considerable time analyzing the code and submitting evidence, only to receive a response that doesn't properly explain the decision.

The report took around three weeks to receive a final response. What concerns me even more is that the response contained no meaningful technical discussion of the evidence I submitted. There was nothing that demonstrated why the reported behavior was not a vulnerability or explained how the alleged duplicate justified the closure.

This raises another question: did a qualified security professional actually review the report? Was it examined by a technical triager who understood the code and the potential impact, or was it dismissed without a proper technical assessment? I have no way to know because TRON DAO provided no explanation that would allow me to understand what was evaluated.

I contacted HackerOne Support to get clarification, but my support ticket was marked as resolved without addressing the actual concerns. Mediation was suggested as a possible option, yet it wasn't available to me. So after waiting weeks for a decision, I was left without a meaningful explanation and without a practical way to escalate the issue.

Honestly, this whole experience raises serious concerns about transparency and accountability. When a security report receives an unexplained closure, the stated reason appears inconsistent with the official status, and support closes the complaint without resolving it, it's difficult not to question whether the process is being handled properly.

FRAUD is a serious word, but when researchers are expected to invest time and effort into identifying security issues while receiving little more than unexplained decisions, the lack of transparency becomes a real problem. I want to know what safeguards exist to prevent reports from being dismissed arbitrarily and whether anyone is accountable for the quality of these decisions.

I'm not asking TRON DAO to accept my report simply because I submitted it. I'm asking for a technically meaningful explanation and a transparent review process. If the report was invalid, explain why. If it was a duplicate, clarify that decision to the extent permitted by confidentiality. Neither should require a researcher to spend weeks chasing answers.

Has anyone here experienced something similar with TRON DAO or another HackerOne program? Have you had a report marked Not Applicable while the response claimed it was a duplicate, with no technical explanation? And what options do researchers realistically have when support considers a complaint resolved and mediation is unavailable?

I'm deliberately withholding the PoC and actionable technical details. My concern here is how the report was handled, not publicly exposing the suspected vulnerability.

P.S: If they dont aswer me I will make public the PoC on every single forum on the TOR network I know, Im not joking, even the ukrainian ones

After months of grinding and bug bounty politics, i finally got my recognition as a pre degree student. Originally my vuln got downplay by a program manager despite being in scope and agreed by platform triager.

Nonetheless, persistance eventually persist as i escalate it to higher national authority by demonstrating the real risk. Though its only reflect xss, i found it through supply chain and it involve a bank entity. A win is a win anyway.

Nothing is imposible if you want it bad enough. Happy hunting!

I submitted a security report to TRON DAO through HackerOne on September 23, 2026. After analyzing the code, I provided technical evidence, including a reproduction and a control case. I'm not going to share the PoC or details that could expose the suspected vulnerability.

On October 15, TRON DAO closed the report as “Not Applicable.” However, their response stated that the report was a duplicate and therefore not a valid issue. No technical explanation was provided, and they didn't identify the alleged duplicate.

So what exactly happened here? If the behavior isn't a security issue, why call it a duplicate? And if it is a duplicate, why provide no meaningful clarification? I spent considerable time analyzing the code and submitting evidence, only to receive a response that doesn't properly explain the decision.

The report took around three weeks to receive a final response. What concerns me even more is that the response contained no meaningful technical discussion of the evidence I submitted. There was nothing that demonstrated why the reported behavior was not a vulnerability or explained how the alleged duplicate justified the closure.

This raises another question: did a qualified security professional actually review the report? Was it examined by a technical triager who understood the code and the potential impact, or was it dismissed without a proper technical assessment? I have no way to know because TRON DAO provided no explanation that would allow me to understand what was evaluated.

I contacted HackerOne Support to get clarification, but my support ticket was marked as resolved without addressing the actual concerns. Mediation was suggested as a possible option, yet it wasn't available to me. So after waiting weeks for a decision, I was left without a meaningful explanation and without a practical way to escalate the issue.

Honestly, this whole experience raises serious concerns about transparency and accountability. When a security report receives an unexplained closure, the stated reason appears inconsistent with the official status, and support closes the complaint without resolving it, it's difficult not to question whether the process is being handled properly.

FRAUD is a serious word, but when researchers are expected to invest time and effort into identifying security issues while receiving little more than unexplained decisions, the lack of transparency becomes a real problem. I want to know what safeguards exist to prevent reports from being dismissed arbitrarily and whether anyone is accountable for the quality of these decisions.

I'm not asking TRON DAO to accept my report simply because I submitted it. I'm asking for a technically meaningful explanation and a transparent review process. If the report was invalid, explain why. If it was a duplicate, clarify that decision to the extent permitted by confidentiality. Neither should require a researcher to spend weeks chasing answers.

Has anyone here experienced something similar with TRON DAO or another HackerOne program? Have you had a report marked Not Applicable while the response claimed it was a duplicate, with no technical explanation? And what options do researchers realistically have when support considers a complaint resolved and mediation is unavailable?

I'm deliberately withholding the PoC and actionable technical details. My concern here is how the report was handled, not publicly exposing the suspected vulnerability.

Edit:

Hey everyone. I previously sent a report with an issue of BAC with privilege escalation, submitted it on 23rd August. It got reviewed on 5th September but marked as N/A all theoretical with no impact but if I believed it to be real then I could send a new report with it.

So I sent the new report on the same day, 5th September containing the impact. It got reviewed on 15th October and marked as duplicate due to a report on 30th August.

Did I miss out on the report being accepted because the first report had no impact even though it was first? Did I mess up because the new report was sent after the report that got accepted?

I've been running into duplicates for some time and I feel like an idiot because of the first report and the new report I sent is another duplicate.

I reported a bug in iOS 27 last month, within 11 days they planned it for fix in fall this year, but i added some impact escalation followups, they again flipped the status to reviewing and no comment on report. Is this normal?

We have fixed issue in our software back in June, and we wanted to obtain CVE-IDs for those issues. We submitted our request through https://mitre.github.io/mitre-cve-roles/cve-id-request/#cvePortal but haven't had the slightest reaction since then, not even after asking for a rough ETA.

I assume they are drowned in AI generated submissions.

Is there any better way to do this. Should we become a CNA ourselves? Or is Bugcrowd a CNA and can provide CVE-IDs? (Although they seem drowned, too.)

A few days ago, I received an invite to a private program on YesWeHack. The problem I’m now facing is that this company also regularly buys pentests from my employer (my primary full-time job is pentester). I haven’t worked on projects for that company myself, though.

The private program’s guidelines specifically say I’m not eligible if I work for a contractor or the company.

Do you think I should leave that program (if so, how do I do that on YWH?) or work on it and report stuff regardless, even though I won’t receive a bounty?

This is their end state (after October 19th). For programs that allow trial reports and where researchers don't met signal requirements, there's a 3 trial limit across all these programs over 90 days.

They're only returned by passing the 90 day window or if a report is marked as triaged or resolved. Or marked as a duplicate of a triaged or resolved (and not public).

This will definitely cut submission numbers and the ability to submit.

I submitted few reports to omarchy when they first launched the program and here's the outcome

They closed 2 as duplicate

And here comes others ,

Every single is marked as n/a , which is clearly in scope and reproducible, im like wth is hell is happening .... dude seriously, they closed as n/a which is in scope

Im not new to bounties, till now I earned around 29k in bounties

Some endpoints does not appear in burp history or can not be intercept idk why is there any solution i saw it in devtools but i wanna send it from burp , like there is reset pass function i can intercept it but i cant intercept change email function

Earlier this week I made this post describing the vulnerability I had and asking for opinions on the severity downgrade. Well, things just got 10x worse. I was asked by the company to try and delete an EUID, as my original vulnerability basically found that the delete enterprise account endpoint accepted any EUID, and they were enumerable + you could validate enterprise accounts. So I tried to delete the EUID using my original PoC. It failed, so they fixed it. Hurray! I reported back my findings with API logs etc. I then wake up 4 days later to them saying:

"Thanks for working with us and running the additional test. We confirmed that the controlled test user was not deleted. Engineering’s testing also shows that the endpoint rejects enterprise user IDs outside the requesting administrator’s enterprise.

Since we weren’t able to reproduce the reported cross-tenant deletion in production, we’re going to close this report. If you’re able to provide new evidence showing that a user in an unrelated enterprise was actually deleted, including the exact request, response, and timestamp, we’d be happy to review it again."

And deducted one point off my Bugcrowd account and marked it as Not Reproducable.

First thought; What the fuck!

I'm genuinely devastated and have zero clue on what to do, desperately need some advice/help. Is this just the reality of bug bounties? I could've VERY easily deleted thousands of their customer's accounts, but instead I submitted my report in good faith. I regret ever working with this company, I'm extremely tempted to drop the name but I feel it isn't right to do so. I'm sorry for rambling at the end here, the finding took weeks and I'm just extremely pissed at the moment.

I've submitted a request for response from Bugcrowd, but I honestly doubt anything will come of it. I didn't save any of the API logs I had of deleting the accounts, but I have the original EUID's belonging to my test accounts while testing this out. Oh well.

EDIT: Sorted it out with the company, turns out it was a misunderstanding on the fix and when my report was submitted. Bounty's been sent out and they've apologised.

Hello,

I applied to synack red team, does having a high EU/NATO security clearance help in getting through process sooner?

What are your current experiences with it?

Thank you.

​

I started hunting again about 6 months ago after a long break. The first 3 months I got lucky and got bugs in 6 programs total - 3 bugcrowd and 3 on HackerOne.

Since then I took a break and came back about a month ago and haven't gotten anything yet.

My question is: should I stick to just hunting on the private programs I have (even though they have good scope), or should I also hunt public programs and go for big targets like Samsung/Google?

Honestly, even private programs have a ton of competition, and *ironically the first bug I got in these last 6 months was actually in a public program.*

Is it correct to think: it's okay to hunt private programs, but I shouldn't limit myself to only those?

Because I feel I am limiting myself pretty bad. I keep testing the targets I already tested over and over again, because I belive that I already understand the scope and features and logic , instead of starting over in a newer target with new competition and stuff.

But I feel I am pretty limiting myself and this is wrong, what do you guys think?

i saw this disclosed report on hackerone https://hackerone.com/reports/3189580 , felt bad for researcher . he literally waiting for months for valid bug at the end he got nothing and team asking error in payout is crazy

Testing an LLM and that is what I got so far, I have been trying to leak internal files or do calls using it , but what I got so far are the model info and the system instructions only.

I can make it do other instructions other than what it's intended to do but I feel this is an info bug.

Moreover , I tried asking it for reading files and executing code, it hallucinate. Respond with fake info not real ones.

Are those reportable or not ??

How to proceed here ??

I want to hunt on an Intigriti program that has been suspended and unsuspended several times recently. Does this pattern usually point to problems like slow triage or delayed bounties, or is it often just the team pausing intake to clear a backlog? If you have hunted on a program like this, I would like to hear how it went. Thanks.

Hey Hackers, I wanna know if "triaged" in Bugcrowd = "triaged" in H1 or not! With other words, does triaged report in bugcrowd With the same degree of acceptance like H1?

Hi everyone,

I've had a pretty frustrating experience with Meta's Bug Bounty program, and I'm hoping someone here has dealt with something similar.

I recently discovered a potential security vulnerability in one of Meta's open-source projects and submitted a report through their official Bug Bounty portal.

About an hour later, my newly created Facebook account was flagged as suspicious, and I was asked to prove I'm not a bot.

I completed the required video selfie verification, but my appeal was rejected and my account was permanently disabled. No further appeals allowed.

I created the account specifically to report the vulnerability. Sorry for being Gen Z and not having a Facebook account already, I guess? lol

The frustrating part is that my report was successfully registered, but I can no longer open the case because Meta redirects me to Facebook, where my account is disabled.

My main questions are:

- Does Meta communicate bug bounty updates and requests for additional information via email, or exclusively through the support portal?

- Has anyone experienced an account suspension while participating in Meta's Bug Bounty program?

- Is there any way to reach an actual person at Meta Security to get this resolved?

I've already contacted Meta Security by email and filed a complaint through an independent dispute resolution body in Germany under the EU Digital Services Act.

I'm particularly concerned because, if the vulnerability is valid and eligible for a bounty, I don't want to lose the opportunity simply because I can't access my account or communicate with the security team.

I genuinely don't understand what I did wrong. I created the account in good faith, used my real identity, and completed the requested verification.

Any advice or experiences would be greatly appreciated. Thanks!

I have reported a bug 3 months ago in a Program which is critical and it changed to "under review". After that I waited 1 month, no reply or no fix was deployed. The fact that the vulnerability is a critical finding that leaks sensitive passports of users through a S3 bucket misconfig. I am messaging every week about updates and there is literally no reply and the fact that they are actually closing other reports that I can see from their program activity is concerning. I have contacted the yeswehack team to take a look and talk with the program, but still no reply. The fact that the triage team from Yeswehack doesn't even care about the researcher's time is concerning. Literally no support from anyone from Yeswehack!!!

Hi everyone,

I currently work as a pentester. I’m comfortable with various vulnerability types and understand how they work under the hood. Recently, I've been trying to transition into bug bounty, but I'm struggling with a bit of a mental block.

I’m anxious that I won't find any bugs because these programs have already been tested by hundreds of researchers. In my day job, I usually test fresh, un-assessed targets, so knowing that a bug bounty scope has already been thoroughly probed makes me feel like everything worth finding has already been patched.

How do you overcome this mindset? How do experienced bug hunters approach well-tested targets? Any advice would be greatly appreciated!

​

I reported few bugs to a private HackerOne program, and all of them were in Pending Program Review. The program recently announced that it’s taking a break and temporarily not accepting submissions.

It’s been 25 days with no response or status change, even after following up. The program’s average time to bounty is 2 days, and I noticed that its total bounties paid haven’t changed since the break started.

Do these reports still have a chance of being reviewed, or do they basically go into a black hole? Has anyone faced a similar situation?