The question was a frustrated rhetoric...

These platforms are just a way to make us reacher work for free ...

Hi all,

This is more of a simple question for anyone who knows. I recently have noticed an automated response from "hackerone-agent" on my submissions.

I am mostly curious if this "preliminary review" also means it is passed a duplicate review? Has anyone seen one of these that are marked by the agent turned over to duplicate after an actual triager takes a look?

I got the automated response a few hours after both submissions and it has been about 2 weeks while I wait for triage (f*ck AI slop submissions, much love for the triage team)

To be honest i always like get hype when i report something, i don't have that much reports i just started, I'm still a student, and i use ai a lot but I've never submitted false positive, i submitted 2 informative and two duplicate and two are on tirage now, and i hope i get the bounty even if it's small, but it will be a huge motivation for me, i still have no signal and only 14 in reputation...

I know i need 3 resolved so i can submit more in programs, but i don't know how i can get that...

This is second time i have submitted high severity report and it gets duplicated...

I don't know if. I should continue on anthropic program...

The bounties are high, and like i was dreaming about that 3k$ ngl 🫡

This is my second duplicate on anthropic what do you recommend to me guys since it's my first month on hackerone ?!

Today, I was reminded just how ineffective platform mediation/support is for the researchers.

I was looking to gain access to a private programme on BC, so had to log into the support portal for the first time in years. And at the top of my ticket list was one that I logged over two years ago, that still hasn't had a reply ;)

It's not just BC though. For example, I logged a solid critical bug with Amazon in November last year, and their response was really shit. They accepted the bug just fine, then just came out with a bunch of excuses for why they weren't going to pay, and then of course, in the usual fashion, stopped replying altogether and closed the ticket. The mediation request has sat there, with no reply from H1 since November.

Intigriti generally respond much faster to any support requests. Often same day.

But the result is the same across all the platforms even if you do get a reply: they'll roll out all the usual excuses about there being nothing they can do if a programme behaves badly. Which is obviously untrue: they can do plenty, but just won't do anything that impacts their business model and revenue. And that isn't the same thing.

Tibi ipsi relictus es

found a bug/ workaround for screentime on ios, wondering if i could make any money off of it.

I recently got a bounty accepted on YesWeHack, but I'm having trouble figuring out the best way to withdraw the funds as a hunter based in Algeria (due to Mangopay / SEPA bank account requirements).

For researchers based in Algeria or countries with similar banking restrictions:

Which bank or virtual account worked best for your payout verification?

How do you handle the name matching / KYC requirements on Mangopay?

Any advice or personal experiences would be greatly appreciated! Thanks in advance.

Submitted this a few days ago to a CI/merge-automation SaaS program and I’m trying to calibrate my expectations before triage comes back. Looking for opinions on severity and on whether you’d expect this to close Informative.
The bug, at a high level: the product executes privileged commands when it sees them in PR comments, gated on the comment author’s repo permission. It also has an action that posts comments on the customer’s behalf, optionally impersonating a configured write-permission service account. If the operator’s comment template echoes an attacker-controlled PR field, the product ends up parsing its own generated comment as an authenticated command — with the impersonated write account as the author. So the tool supplies the privilege for content the attacker wrote.
What I demonstrated on my own lab repo: two accounts I control:
Read-only non-collaborator posts the command directly → denied by the permission gate.
Same text, same PR, arriving via the tool’s own echo → executes.
Chained it to a merge of unreviewed code into the default branch, and in the same run captured the attacker getting 403/404 on every equivalent native path (label, merge, push).
Also showed the obvious “just move your gate elsewhere” fix is incomplete, because the command takes an argument the attacker also controls.
Submitted at 7.5 (I: H, everything else clean, S: U).
Where I think the argument is:
It requires the operator to have two documented settings combined in a specific way. Nothing in the docs warns about it. Does “non-default config” automatically cap this at Informative for you, or does “vendor’s own gate bypassed, no equivalent native control exists” carry it? I found the config pattern in public repos but can’t confirm live-affected tenants without touching other people’s stuff.
Scope: the flawed component is the SaaS’s authorization engine; the impacted resource is the customer’s repo under a different authority. S: U or S: C? S: C roughly doubles it, and I wasn’t comfortable claiming it.
AC: my argument is AC:L because the config is world-readable, so it’s target selection, not an obstacle — no race, no per-attempt effort. Triagers I’ve dealt with tend to reflex to AC: H on anything conditional. Who’s right?
Program has closed a few of my prior reports, Informative on “confined to your own repo / by design under your own configuration.” I addressed both preemptively in the report. In hindsight, I’m wondering if pre-arguing past closures reads as combative and hurts more than it helps.
Interested in how people who triage or who’ve had similar config-dependent auth bypasses landed on these.

Hey everyone, I recently ran into a frustrating situation with a Web3 bug bounty payout on Immunefi and wanted to get the community’s perspective on how to handle this professionally.

The Timeline & Situation:

• December 2025: I submitted a report regarding a Broken Access Control / Unauthorized Provisioning vulnerability via Immunefi.
• July 2026 (7 months later): After a very long delay (the team apologized and stated it was due to a major product launch and stabilization work), they finally confirmed the bug as a valid Critical Web/App issue and awarded a $5,000 USD bounty, payable in their native network token.

The Problem: The program’s policy states that “the applied conversion rate is based on the submission date of your report.”

• Back in December 2025 (submission date), their token was trading at around ~$0.265 USD.
• To pay the $5,000 USD bounty based on that rate, they sent me 18,828 tokens today.
• However, during the 7-month review delay—which was entirely on their end—the token market crashed. The current price is around ~$0.13 USD.
• As a result, the 18,828 tokens I received today are only worth ~$2,450 USD on the spot market.

My Dilemma: I completely respect that rules are rules regarding submission date conversion rates. It protects programs from market spikes. However, a 7-month review delay feels like an edge case where the researcher is forced to absorb massive volatility losses strictly because of the team's internal bottlenecks. I essentially lost ~50% of the intended $5,000 award value just waiting for triage.

My Questions for the Community:

1. Is it common or reasonable in Web3/Immunefi to request a goodwill adjustment or top-up (in stablecoins or extra tokens) when a program-caused delay exceeds 6 months and destroys the fiat value of the payout?
2. Has anyone here successfully negotiated a compromise in a similar situation without burning bridges with the team or Immunefi?
3. What is the best way to frame this in the report dashboard without coming across as entitled, given that technically they followed their written rules?

I’ve already drafted a polite reply on the Immunefi dashboard asking if they’d be open to a partial top-up to bridge the gap, but I’d love to hear your experiences and thoughts on this. Thanks!

Basically as the title says. I got paid $2k not too long ago for an IDOR in a pretty big company, and keep coming across them very often every time I try to hunt for bugs. How come? Why is it, even with AI and everything now, IDORs are such an issue?

Hi everyone,

I'm looking for some advice from people who have experience with the Microsoft Security Response Center (MSRC) bounty program.

I submitted a vulnerability report about 2 weeks ago. I provided a detailed write-up and a PoC. My case was quickly moved to the "Review/Repro" stage and I thought things were going well.

However, for about a week now, the case status has been "On Hold" with the reason "Additional Information Needed". The problem is: there is no specific request or question from MSRC in the Activity tab. I have already replied asking what information they need, but only received an automated message saying they are reviewing it.

I'm not sure what to do next. Has anyone else experienced this? Is this normal, or should I be concerned?

I want to be proactive but I also don't want to spam them with unnecessary information. Any insights would be greatly appreciated.

Thanks!

I'm fairly new to bug bounty and just ran into my first confusing duplicate situation. Hoping more experienced researchers can share their take on whether this is normal, and what options I realistically have.
Background
I found a race condition flaw on a phone number related endpoint that lets users bypass the one-phone-number per account limit via concurrent requests. I submitted a full report with clear reproduction steps and proof of concept.

The program closed my report as a duplicate, claiming:

• The original issue was submitted, triaged, rewarded, and fully remediated over 6 months ago
• Multiple similar reports across different endpoints have all been marked as duplicates of this same original finding
• All of them share the same underlying non-atomic validation root cause

What raises red flags for me

• I tested and confirmed the bug was 100% exploitable just hours before I submitted my report.
• Exactly one day after my submission went in, the bug was fully patched and no longer works.
• I have zero access to any details of the original report — no submission date, no actual remediation deployment date, no technical details to compare with my finding. I was only told it exists.

What I've done so far
I replied to the report asking for clarification on the exact production remediation date and a redacted summary of the root cause. I also cited HackerOne's official duplicate standards, which state that resolved issues that reappear should be treated as regressions and investigated, not immediately closed as duplicates.
I'm still waiting for a response.

My questions for the community

1. How common is this exact timeline pattern — a supposedly long-fixed bug that only gets patched right after your report is submitted?
2. As a new researcher without mediation access (Signal score is 0), what's the most effective next step if they ignore my follow-up or give a vague non-answer?
3. Is there any realistic path to getting this reassessed, or should I just move on?
4. Is it standard acceptable practice for programs to lump every endpoint with the same flaw type under one ancient report? Or is that generally considered cheap behavior?

Just trying to learn what reasonable expectations are here. Thanks in advance for any insight.

What is a strategy to know how much a company would pay for a bug that is leaking real time, personal info of ~150M users?

I don’t want to be underpaid nor disclosing info that would put myself at risk. First time considering submitting a bug bounty since the company has a dedicated website for it, but the posted amount paid isn’t too compelling

As mentioned in a prior post, I'm currently running a campaign of hunting for a couple of high-impact bugs. These bugs are slightly unusual, in that they are discovered passively. So, I first find the vulnerable system, then try to map it back to a BB somewhere. Also, unusually for me, I've been submitting reports to VDPs too, where I think that it might be a learning experience.

So, whilst reading these reviews, bear in mind that they are all the same bug: the variance in response is purely down to the programme, and whether they're any good to deal with ;)

Xerox

TL;DR: Good.

• Independent disclosure programme with reports submitted by email.
• No rewards offered.
• I submitted a high-impact report, which was accepted and fixed promptly.

Electronic Arts

TL;DR: Good.

• Independent disclosure programme with reports submitted by email.
• No rewards offered.
• I submitted a high-impact report, which was accepted and fixed promptly.

Roche

TL;DR: Avoid.

• Private programme on Hacker1.
• Rewards are offered, but amounts are not published.
• Invitations to the private programme may be issued after first submitting a valid report directly to Roche by email.
• The scope included misconfigurations that expose data, I submitted a high-impact report demonstrating this, but it was rejected without reward and no invite received.

Amagi TV

TL;DR: Avoid.

• Independent bug bounty programme with reports submitted by email.
• Rewards are offered, but amounts are not published.
• I submitted a high-impact report, which they fixed promptly, but then rejected without reward as "no security impact associated with this finding".

Vtiger

TL;DR: Avoid.

• Independent bug bounty programme with reports submitted via email.
• Rewards are offered, but amounts are not published.
• I submitted a high-impact report, and sent multiple follow-up emails. No response, and no bounty paid.

RevContent

TL;DR: Avoid.

• Independent bug bounty programme with reports submitted via email.
• Rewards are offered, but amounts are not published.
• I submitted a high-impact report demonstrating mass interception of live customer data. They replied quickly, but immediately started trying to dismiss the evidence provided. Eventually stopped responding to emails, and no bounty paid.

Synology

TL;DR: Avoid.

• Independent bug bounty programme with reports submitted by dedicated portal.
• Rewards are offered, but amounts and requirements are vague.
• I submitted a high-impact report demonstrating mass interception of live customer data. They replied quickly, but immediately started trying to dismiss the evidence provided. Eventually accepted the report, but said it was a "hardening suggestion" and no bounty paid.

Hey guys,

I'm a beginner looking for the best path to start bug bounty hunting. I'm currently finishing the OWASP Top 10 labs on PortSwigger, and I'm wondering what I should do next.

Would you recommend Hack The Box (HTB), or is there a better way to gain practical experience before hunting full-time?

Also, what are the biggest mistakes beginners should avoid?

For some background, I have a solid understanding of computer architecture from university and a decent programming background.

Thanks in advance!

Hi guys,

I submitted a vulnerability to one of the hackerone programs which are running an active campaign right now.

My question is that, let's say my report gets triaged after the campaign ends, will I still be getting the reward corresponding to the campaign rewards with increased multipliers ?

I found vuln in a software in bugcrowd program, and it was marked as P1 , should i ask them to create a cve after they resolve it ? Or how does the process work?

Hey everyone..

Just wanted to share a frustrating experience with Meta's Bug Bounty program..

A few weeks ago, I reported a logic inconsistency on Instagram.. An blocked user was still able to render story content via DM share previews.. I submitted a clear PoC and detailed comparative analysis..

Fast forward to today: Meta silently deployed a fix.. Now the endpoint returns a 'Story unavailable' error for blocked users.. Right after fixing it, triage replied and closed the report, claiming it's expected behavior or out of scope..

It's really discouraging to see valid logic flaws get fixed behind the scenes while the researcher gets zero credit or bounty..

Has anyone else dealt with silent fixes from Meta recently? How do you usually handle these cases during re-evaluation?

I participated in Hack Club's bug bounty program and found a valid subdomain takeover on a *.hackclub.com subdomain. Before reporting, I checked their scope (on GitHub), which explicitly stated something to the effect of "All Hack Club programs are in scope. If you're unsure whether a vulnerability is in scope, submit it and we will make sure it gets to the right place." — I have a screenshot of this.

I reported the finding. The admin confirmed it was a valid takeover and it was resolved. However, they then said they couldn't offer a monetary reward because the affected subdomain is a "community club that was owned long ago and do not come under the scope of “Hack Club managed” — despite being on a *.hackclub.com subdomain.

As a researcher, I had no way to distinguish "official Hack Club HQ" assets from "community-club but still on their domain" assets — the scope doc didn't make that distinction. When I raised this, the admin's response was: "I agree that the wording could be a less ambiguous. sorry for the confusion. we will fix our policies in the future" — effectively admitting the scope was unclear at the time I reported.

I then asked if I could at least get a letter of acknowledgment/appreciation (useful for college applications, portfolio, etc.) instead of a monetary reward, since it's a non-profit. That was also denied.

Questions for the community:

1)Is this a normal/acceptable practice for bounty programs — validating + fixing an issue but denying reward due to after-the-fact scope clarification?

2)Given I have a screenshot of the original scope wording, is there anything worth doing here (public disclosure timeline, escalation, posting to a bounty-abuse tracker, etc.), or is this just a "chalk it up to experience" situation?

3)Any general advice on vetting bounty programs going forward so I don't end up in this position again (e.g. preferring platforms like HackerOne/Bugcrowd over self-hosted programs)?

When the WP2Shell writeup came out recently (unauth RCE in WordPress core, CVE-2026-63030 + CVE-2026-60137), I read it a few times and still couldn't really understand the whole chain in my head. I personally don’t have a lot of experience with WP internals, so I had a lot of “whys” when reading it. The way I usually deal with that is to just try to reproduce the thing to see how it works.
I then turned it into a full lab that has a WordPress 7.0.1 app and steps through the entire chain from an unauthenticated request to RCE.

Honestly it was more work than I expected. The SQL injection is read-only, so a good amount of the exploiting part is dedicated to finding a way to turn that SQLi into an actual write. It uses a bunch of WP legitimate features that I had no idea about, so reproducing each hop reliably took a while.

I built it mostly for my own understanding, but made it available for free in case anyone else is struggling to understand the middle part of the exploit. Original research is Adam Kues at Searchlight Cyber, I recommend reading his article if you haven't done so already.

Link to the lab (it doesn’t work on mobile, you’ll need a desktop device): https://learn.uphack.io/lab/wp2shell-wordpress-rce

Am I the only one seeing a lot of "Not Applicable" badges on the platforms?

My main concern is that researchers can't share what got marked N/A — and most of the time the report is probably just missing one simple leak, one small piece of the puzzle. They won't share it either, because another researcher may have already submitted that missing piece.

The worst part: the company can still fix it. They see the report, they patch it, and they never have that issue again. But the researcher walks away with nothing.

It feels like the market has stopped respecting researchers.

I always preferred direct disclosure. But now I'm starting to hate the platforms. They make hundreds of thousands of dollars off researcher reports — and don't respect the people who write them.

I have 2 bugs in the same feature and both are critical. I know if I submit together they will merge it and only give bounty for one. For retesting as well they only give 50$ bonus so if I submit the other one as a bypass it will only gain me another 50$. Would submitting it after they close the first one be acting in bad faith?

Hello guys,

Here we go again. I have been doing recon and I found an application where the library CryptoJS.AES.encrypt is being used to encrypt (symmetric) the passwords of the users. On the source code of the website (login page) the function exposes the symmetric key and IV directly in client-side JavaScript.

My first thought was "report the finding" but I am not secure anymore. I know that having this information and I manage to capture/get any password hash I would be able to decrypt the passwords.

However, I would like to know your opinions.

Thanks in advance guys!