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

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 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.)

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.