Intel has suspended its paid bug bounty program and switched to a VDP with no monetary rewards.
Could this decision be related to the growing flood of AI-generated vulnerability reports, or is there another reason?
Curious to hear the community’s thoughts on this move.
Old Bug Bounty Program: https://app.intigriti.com/programs/intel/intel/detail
New VDP: https://app.intigriti.com/programs/intel/intelvulnerabilitydisclosureprogram/detail

I need advice from experienced bug bounty hunters about a report that was closed as Informative despite my attempts to explain the attack scenario and demonstrate the security impact.

For privacy and responsible disclosure reasons, I am withholding the affected company's name, target domain, exact endpoints, confirmation tokens, report ID, and other identifying details.

1. The vulnerability I reported

I discovered unexpected behavior in an application's email-change confirmation flow.

When a user changes their account email address, the application sends a confirmation link. I found that modifying the URL path while keeping the original query parameters could trigger different behavior.

Under the conditions I tested, the modified URL appeared to complete the email change and establish an authenticated session for the affected account without requiring the account password.

I tested this with the account owner's permission.

My concern is that users may believe this is an ordinary email-verification link, not a link that could potentially grant someone access to their account.

1. The triage team's initial response

HackerOne Triage:

«Your report has passed the preliminary review. Please note that this does not confirm validation. The next step is to validate and reproduce the issue and evaluate its accuracy and security impact.»

At this point, I believed the issue would be investigated further.

1. The report was closed as Informative

After reviewing the report, the triage analyst responded with the following reasoning, paraphrased to remove identifying details:

Triage Analyst:

«The issue does not appear to have significant security impact. An attacker would need access to the victim's account to initiate an email change. If the attacker can initiate an email change to an address they control, they already have sufficient access to compromise the account through standard means, such as changing the password.

The modified confirmation link does not provide additional access beyond what is already available to someone who controls the account session. Without a realistic attack scenario in which the attacker lacks initial account access, this is a design concern rather than an exploitable vulnerability with meaningful impact.

Therefore, the report is being closed as Informative.»

1. My first response to the triage team

Me:

«I think there has been a misunderstanding. I never claimed that an attacker could independently change the victim's email address.

My concern is that if a user initiates an email change and the confirmation link falls into an attacker's hands, the attacker may be able to exploit it.

A user may voluntarily share the confirmation link because they believe it is harmless and only confirms an email change. They may not realize that someone receiving the link could potentially gain full access to their account without knowing the password.

I would appreciate it if you could reconsider the report.»

1. The triage team's response about mailbox access

Triage Analyst:

«The attack assumes that the victim either shares the unused confirmation link with the attacker or that the attacker obtains it somehow. However, the confirmation link is delivered to the victim's inbox specifically to confirm the email change.

An attacker would therefore need direct access to that mailbox to retrieve it. At that point, the victim's email account has already been compromised, which is a broader security issue in itself.»

1. My explanation of the social-engineering scenario

Me:

«I understand your argument about mailbox access, but I believe voluntary link sharing is a separate attack scenario.

For example, an attacker could persuade a user to share an email-change confirmation link by claiming that it is only a routine verification link. The user might refuse to share a password-reset link because they understand its significance, yet share this confirmation link because they do not recognize the potential risk.

If the recipient can modify the URL path and use the link to gain access to the account, the attack does not necessarily require direct access to the victim's mailbox.

I also provided a reference to a previously published security report involving a similar general class of issue. I asked the triage team to reconsider the threat model.»

1. My final attempt to clarify the issue

Me:

«The user may trust the link and voluntarily share it during an ordinary conversation. If they believe it is just an email-verification link, they may not understand that it could be used to access their account.

The attacker can then modify the URL path and potentially obtain account access without knowing the password.

My concern is that the security implications of the link are not obvious to the user. I would appreciate a review of this specific scenario rather than an assessment based solely on whether the attacker already has mailbox access.»

After these exchanges, I was unable to obtain a meaningful reassessment through the available process. The report remains closed as Informative.

1. Why I disagree with the conclusion

I understand that a confirmation link must be obtained somehow, and that possession of such a link is an important prerequisite for this attack.

However, I believe there is a distinction between:

- An attacker independently compromising a victim's mailbox.

- An attacker persuading a victim to share a link because the victim misunderstands its security significance.

- An application treating an email-change confirmation link as a mechanism that can establish an authenticated account session.

These scenarios have different threat models.

I am not claiming that every user will share such a link, or that the vulnerability is automatically eligible for a bounty. My concern is whether the application should allow a confirmation link to grant account access in a way that the user would not reasonably expect.

1. Questions for other bug bounty hunters

2. Is the described behavior a valid account-takeover vulnerability, or is it reasonably classified as Informative because the attacker must first obtain the confirmation link?

3. How would you demonstrate that the modified endpoint grants additional privileges rather than merely completing the intended email-change process?

4. Is voluntary sharing through social engineering a sufficiently realistic attack scenario for a report like this?

5. What options remain when a triage analyst rejects the threat model and the available mediation process does not resolve the disagreement?

6. If you have encountered a similar situation, how did you handle it professionally?

I have experienced a similar difficulty with a previous report, so this has left me unsure how to proceed.

I am sharing this discussion to seek technical feedback, not to attack the company or encourage anyone to target the service. I am intentionally withholding all information that could identify the affected application or enable exploitation.

I welcome honest criticism if my reasoning is flawed. I would particularly appreciate feedback from researchers who have handled authentication vulnerabilities and disputed triage decisions.

What would you do in my position?

Also I have an "PUBLIC KEY" from that

(Disclosure: I work at Gray Swan, where I run the Frontier Lab Safety team and the Arena)

We just launched our largest-ever AI red teaming challenge, at the request of Anthropic, Meta, Google DeepMind, Reflection, and our other lab sponsors, who want to see just how strong their auto mode defenses are and to what degree prompt injections on coding agents are solved problems.

It's been live for two days, but we need more breaks! --which means the fruit hang low; right now it's only 4 breaks out of 84 targets to get on the prized leaderboard for white box, and even 1 break out of 52 on black box would currently get you fifth place ($2500).

Experience with AI red teaming is helpful, but for this, general bug bounty experience is probably more important, so imagine some of y'all would be quite good at these kinds of exploits.

Check it out: https://app.grayswan.ai/arena/challenge/ipi-black-2026?panel=rules

It seems like mostly when report looks ai type triage report it as n/a, there was once a triager who asked me for an edit and i did the edit then when i submitted followup, another weird tirager seemed like he is replying to different report, what you guys think?

Hey everyone, hope youre fine

A few months ago, I reported a vulnerability on Bugcrowd. It was marked as a duplicate of another report involving a different vulnerability.I explained that my finding was unrelated to the other report, but never received an actual response addressing the technical differences. Eventually, my report was marked as Resolved.Later, I retested the issue and confirmed that it was still there, so I reported it again. This time, it was marked as a duplicate of yet another report involving the same endpoint.
The thing is, these are not just two different ways of exploiting the same bug. They involve different code paths, different root causes, and different fixes. The other vulnerability involves a file upload leading to Stored XSS, while mine is related to regex handling and iframe content spoofing. Fixing one does not necessarily fix the other.
I've now submitted a Request for Response, but I'm wondering what happens if the triage decision itself is incorrect.

Has anyone managed to get a report reviewed again after being marked as a duplicate? Is there a way to have Bugcrowd reconsider the decision when you can demonstrate that the findings have different root causes and require different fixes?

I'd appreciate hearing about your experiences. I'm mainly trying to understand how to handle this situation properly, especially when the original issue remains reproducible.
Thanks!

As far as I calculated, I should be able to submit reports without waiting for the triaged one to be processed according to their new documentation. Can anyone confirm if this is working as intended or something is wrong.

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?

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.

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 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?

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!

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

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.

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.

​

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?

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

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.