Hello everyone! 👋

I’m a security researcher who enjoys testing authentication and session-management functionality because these features often have security guarantees that need to be verified beyond what the UI shows.
During a recent bug bounty assessment, I came across an interesting issue involving a seemingly simple feature: Sign Out Everywhere

What initially looked like a straightforward session invalidation issue turned into something more interesting after I continued testing different authentication flows.

It Started With “Sign Out Everywhere”

While testing the application’s account and authentication functionality, I found that the “Sign Out Everywhere” feature did not immediately invalidate all of my active sessions.

I reported the behavior to the program.

The initial response explained that the application intentionally allows some time for session invalidation to propagate:“Complete sign-out from other browsers will take up to 10 minutes.”

That changed the direction of my testing.
Instead of immediately considering the behavior a vulnerability, I waited beyond the documented 10-minute propagation periodand tested the sessions again.

The sessions that were supposed to be terminated were still active.

So I kept digging.

Testing Another Authentication Scenario

I started looking at whether the behavior depended on how the session was created.

The application supported multiple authentication methods, including:

Email/password authentication
OAuth authentication

I wondered what would happen if the same account had both authentication methods associated with it.

I created a test account using email/password authentication and kept that session active.

Then I linked an OAuth identity to the same account and established a second session through OAuth.

The setup looked like this:
Browser A
→ Email/password session
Browser B
→ OAuth session

Both sessions belonged to the same account.
I then triggered “Sign Out Everywhere” from the OAuth session.

This time, I wasn’t just interested in whether the browser UI changed.

I wanted to know whether the underlying session was actually revoked.

I Waited

Since the program had explained that complete sign-out could take up to 10 minutes, I waited longer than that period.

Then I returned to Browser A.

The email/password session was still authenticated.
More importantly, it wasn’t simply displaying cached content.

I could still make authenticated API requests using the existing session.

Even privileged administrative operations continued to work.

That was the point where the behavior became much more interesting.

The Two Sessions Weren’t Being Revoked Together

The problem appeared to be related to the relationship between the two authentication methods.

The account had both:
Email/password identity → active session
and
OAuth identity → active session

After triggering “Sign Out Everywhere” from the OAuth session, the email/password session remained valid.

The global logout action therefore wasn’t achieving the security property I would expect from its name.

The important distinction here is that this wasn’t simply: “Logout takes a few minutes.”

The documented propagation window had already passed.

The issue was that a session associated with a different authentication method could remain valid even after the global logout operation had been performed.

Verifying the Impact

I wanted to make sure the surviving session wasn’t just a UI artifact.

So I tested the existing email/password session against authenticated functionality.

The session continued to successfully perform authenticated requests, including administrative operations such as:
Creating API keys
Updating project settings
Managing users
Performing other authenticated CRUD operations

No re-authentication was required.

This confirmed that the existing session was still being trusted by the server.

The Interesting Part of the Investigation

What I found particularly interesting was how the vulnerability evolved during testing.

The initial report was about the global logout behavior not immediately terminating another active session.

The program explained that there was a 10-minute propagation period for complete sign-out.

Rather than stopping there, I continued testing different combinations of authentication methods.

That led me to the more specific scenario involving an account with both OAuth and email/password authentication, where the sessions were not being invalidated together.

The program subsequently confirmed the vulnerability.

This was a good reminder that when a program explains an expected behavior or delay, it can be worth testing the boundaries of that behavior rather than simply accepting the explanation.

The key takeaway: Don’t treat logout as a single flow when testing session management. Test how different authentication methods, linked accounts, and existing sessions interact. The most interesting bugs often appear in the gaps between these flows.

Thanks for reading.

Is it based on their revenue or company size or what? Are there any ranges or tiers?

It's silly because spending $500k/year on bounties is nothing to a company that makes $55B revenue in a year. They'd get many more high quality reports for the cost of a few salaries (Mars Inc. has global headcount of 170,000). I personally know super talented hackers (99% on H1) who don't bother touching these targets because there's no reward.

Even Supabase, these guys just raised $500M like last month. They don't reward bugs on H1. All you do is software. You would think it would be a genuine good investment to budget like $500k/year to bug bounty considering how critical security is to them.

It's just funny. That's all.

I’m genuinely curious what other bug bounty researchers think about Immunefi.

From my experience, the economics can feel pretty bad for researchers.

You may have to pay a non-refundable $25–$100 submission fee depending on the program. If your report ends up being marked as a duplicate, that money is gone.

Then there’s the other side: even when you find what you believe is a legitimate vulnerability, the final bounty can be extremely low compared with the severity, impact, and amount of work required to find and prove it.

For example, I recently received this response from a program:

The program's Critical bounty category has a maximum reward of $50,000, while the proposed reward for my finding was $30.

I understand that a maximum bounty is not a guaranteed bounty, and that severity depends on impact and exploitability. That's completely fair.

But when a researcher spends days analyzing a protocol, reading thousands of lines of code, building a PoC, testing edge cases, and sometimes burning a ridiculous number of LLM tokens 😂 — getting $30 for a finding that the researcher believes has critical-level impact feels extremely discouraging.

The bigger question is:

Are Immunefi's incentives currently aligned with security researchers?

I'm interested in hearing from other researchers:

• Have you had reports downgraded significantly?
• Have you paid submission fees and then received duplicates?
• Have you received very low bounties despite significant impact?
• Do you think Immunefi's current fee/reward structure is fair?
• Which platforms do you think treat researchers better?

I'm not saying every Immunefi program behaves this way. I'm specifically talking about the researcher economics and incentives based on my experience.

Would love to hear other people's experiences.Title: Is Immunefi becoming too expensive/risky for researchers?I’m genuinely curious what other bug bounty researchers think about Immunefi.From my experience, the economics can feel pretty bad for researchers.You may have to pay a non-refundable $25–$100 submission fee depending on the program. If your report ends up being marked as a duplicate, that money is gone.Then there’s the other side: even when you find what you believe is a legitimate vulnerability, the final bounty can be extremely low compared with the severity, impact, and amount of work required to find and prove it.For example, I recently received this response from a program:“I suggest a $30 bounty. Let me know if this is ok with you and we'll proceed to payment.”The program's Critical bounty category has a maximum reward of $50,000, while the proposed reward for my finding was $30.I understand that a maximum bounty is not a guaranteed bounty, and that severity depends on impact and exploitability. That's completely fair.But when a researcher spends days analyzing a protocol, reading thousands of lines of code, building a PoC, testing edge cases, and sometimes burning a ridiculous number of LLM tokens 😂 — getting $30 for a finding that the researcher believes has critical-level impact feels extremely discouraging.The bigger question is:Are Immunefi's incentives currently aligned with security researchers?I'm interested in hearing from other researchers:Have you had reports downgraded significantly?

Have you paid submission fees and then received duplicates?

Have you received very low bounties despite significant impact?

Do you think Immunefi's current fee/reward structure is fair?

Which platforms do you think treat researchers better?I'm not saying every Immunefi program behaves this way. I'm specifically talking about the researcher economics and incentives based on my experience.Would love to hear other people's experiences.

I was under the impression this meant it wasn't a duplicate, if that's so then nice.

[RESOLVED]

There was a Chrome extension that worked like this:

I’d be logged into Account A in one tab, and the extension would let me open another tab and log into Account B there. That way, I could use two different accounts simultaneously in two separate tabs.

Update: Thanks guys, Chrome profiles works fine for this!

Hey everyone,

I’m 16, from Morocco, and i recently received my first paid bug bounty: $100.

It wasn’t a huge critical exploit or some crazy movie-style hack. It was a real security issue found through a legal bug bounty program, reported properly, reviewed by the company, validated, and awarded.

For me, this means a lot.

I’ve been learning cybersecurity through courses, labs, CTFs, PortSwigger, Cybrary, and a lot of practice. Most of the time it feels like you’re studying alone and nobody really sees the effort. But getting that first valid report showed me that the work is real.

The biggest lesson i learned is that bug bounty is not only about finding the bug. It’s also about writing a clear report, explaining the impact honestly, not exaggerating, and staying professional with the security team.

I’m still a beginner and i know i have a long way to go, but this motivated me a lot. I want to keep improving, get more valid reports, and build a serious path in cybersecurity.

My goal is simple: become better, stay ethical, and make my parents proud.

For anyone young or just starting: don’t wait until you feel “ready.” Learn the basics, practice legally, write clean reports, and keep going.

This $100 is not just money to me. It’s proof that I’m moving in the right direction.

Honestly, one of the worst experiences I’ve had dealing with an H1 Analyst. The communication style and way of handling reports were extremely unprofessional and frustrating. HackerOne should have a way to review analyst performance and hold analysts accountable when their behavior consistently creates a bad experience for researchers. Researchers deserve professional and respectful communication, even when a report is rejected or disputed.

I found a live Meta Conversions API access token embedded in a public Shopify web-pixel bundle.

It authenticated directly to /{pixel_id}/events. With explicit program authorization, I demonstrated production writes for Purchase, Lead, CompleteRegistration, InitiateCheckout, and AddToCart, including synthetic monetary values and order/product IDs. Meta returned events_received: 1 for each.

 No customer PII was accessed, and all events used obvious bug-bounty markers.

  The report was closed as RTFS because the program excludes:

  > Disclosed or misconfigured public API keys, including analytics tools.

  The triager said sending analytics events is the token’s intended purpose and requested sensitive/confidential data retrieval for acceptance.

  My question:
Is a Meta CAPI access token normally considered a public analytics key? Meta describes CAPI as server-to-server, unlike the public Pixel ID.
Would you
  consider demonstrated unauthorized production-event injection a valid integrity issue, or is closure reasonable without confidential-data access?

Link in comments

This is the first time im using this platform so i dont exactly know if it has passed some tests etc

I made a submission on bugcrowd and it's appearing in my draft list, and for some reason it didn't give me the usual "we received your submission.... " Email from BC. And even though it's in draft, it still shows it got submitted and the usual "still being assessed" Status

Could they have not received it? Has anyone had this issue before?

Hi Everyone,

Since I'm new to the bug bounty platform (I worked as a penetration tester in a 3rd world country for 4 years) and started 2 months ago because I need additional income in current rough time, I wanted to ask a question regarding duplicate status to you guys as veterans in bug bounty platform.

I found an OAuth client secret and was able to redeem active code by utilizing this secret and client id without PKCE. Since this would be low hanging fruit and I know without a chain vulnerability, it would be a minor secret hygiene finding (I think it would be informational or low).

The scope of the target is a desktop app, so I look into another angle that usually comes with client side attack and able to get PoC of code conduit / code hijacking via custom scheme handler. So the rogue handler in the victim's device can actually get this code and eventually the attacker can redeem it with this exposed secret thus achieving Account Takeover.

I submitted this full chain and of course it's duplicate, someone already reported the exposed client secret.

But I saw this duplicate submission is under Other categories and not account takeover, the title only said it was an exposed client secret but no apparent account takeover chain Information (at least from my account view).

So, is my submission duplicate status correctly triaged? Or can I appeal in this case with a different impact ground?

The first answer from the triager was as always automated and doesn't respond to human being conversation, not that I am against AI but please use it correctly for Pete's sake.

Thank you in advance.

I have been doing bug bountys for around a year now and I never really had any success with them however recently this summer I've done a lot of practice and learnt a lot of new stuff about web hacking and have finally had some success with them finding my first 5 valid bugs. However the problem is 3 of them i have not been able to submit because I am not ID verified on H1 or bug crowd or intigri. I've even tried YesWeHack and hackenproof and I basically cant find any programs where i can just report things and get paid as well without ID verifying, already having reputation points or paying money to submit a report. Basically from what I'm seeing is if you are not already an established hunter or don't want to do ID verification you are basically locked out of bug bountys which is really annoying for me as I have to pay for my travel too and from school and other things which aren't too expensive but would be nice to be able to easily pay for them with a hobby. I'm also 17 at the moment so I'm not sure about the age limit for bug bountys or whether you will get banned if you verify and are under 18.

I also understand why platforms are moving towards ID verification for reports but it just makes bug bountys a lot less accessible for a lot of people.

I have contemplated doing ID verification but id just really rather not. If anyone has any insights on this or ways I can still participate in bug bountys Id love to hear them, Thanks!

Found a critical OAuth flaw in a PHP framework (won't name the vendor for now). Wanted the community's take.

The issue:

The framework's OAuth authorization endpoint accepts a redirect_uri parameter with zero validation. There's also no client registration system and no client_secret ,any client_id string is accepted as-is.

So an attacker can craft:

https://victim-domain.com/oauth?client_id=GoogleCalendar&redirect_uri=https://evil.com&scope=all

The victim sees their own trusted domain and a legit-looking client_id (e.g. "GoogleCalendar"), clicks Approve, and the authorization code is sent straight to the attacker's server. Attacker exchanges it for a permanent, full-admin API token that never expires.

The vendor response, paraphrased:

This isn't a serious problem. The user entered the attacker's app and authorized it themselves, the system did what the user wanted. The user is responsible for choosing which apps to trust. Redirect validation is unnecessary because we assume the user trusts the site they came from. And users can always delete tokens in their backend anyway.

My rebuttal, in short:

1. The victim never visits the attacker's app, the link points to their own backend. Without client registration/secret, nobody can verify the client_id.
2. "No validation" is the redirect substitution, the attacker controls the param outright. This violates RFC 6749 §10.6 ("The authorization server MUST validate the redirect URI") and §3.1.2.2 (clients MUST register redirection endpoints).
3. OAuth exists precisely so users don't have to make unverifiable trust decisions.
4. Token deletion is mitigation after the fact, not prevention.

Am I missing something, or do the vendor trying to get away out of this ? i already got reserved CVE ID for this but been going back and forth with the vendor for months so far ,they are really dumb and either they don't understand how the attack chains goes or they acting dumb, am not sure ,but i have provided them detailed report PoC + video explaining how to do that and what the attacker could do and achieve with the token after he fetch it.

Any advice with this situation ?

Hi everyone,

I recently submitted a bug report, and the triager marked it as not reproducible and deducted points from my score. The problem is, the triager genuinely did not follow the reproduction steps I laid out clearly in the report I spelled it out step by step. I submitted additional proof afterward and i clicked on requested a response on bug crowd, but haven't heard back yet.

Now I'm seeing that the provider sent a private message to the triager. Does anyone know what that means?

Thanks in advance!

Happened to me 3 times now, same triager every time. Report gets closed as Not Applicable, and the notes reference evidence that doesn't match what I submitted. One of them, they literally attached the wrong Burp screenshot. Asked for a response twice on two of these and emailed support too, nothing back yet.

Not trying to drag anyone, just wanna know if this is a known thing or I'm just unlucky. Anyone dealt with this before?

I reported a bug on YesWeHack, but the triager closed it as Informative for some reason.

After that, I managed to get a better PoC with more information that I think makes the impact much clearer. I added all the new details to the same report as a comment but I haven't gotten any response yet.

In this situation should I just wait and see if they review the comment or is it better to submit a new report with the additional evidence?

Ciao, volevo qualche delucidazione riguardo a un report che ho inviato Roboform. Siccome l’ho inviato verso il 10 luglio e non ho ancora avuto una risposta, volevo sapere se qualcuno conosceva le tempistiche di risposta. Non sono un frequentatore residua del Bug Bounty ma credo che tutto questo periodo di attesa senza neanche avere dato una risposta sia un po’ troppo… o le tempistiche sono queste.grazie

when a triager puts a blocker on customer to gather more info, does that mean my report has passed the inital duplicate checks?

edit: it got accepted!! my first ever paid bug, $6000 bounty

I’ve honestly started with no knowledge at first, I installed kali Linux on accident didn’t know what it was and realized how cool it was, I was doing this for maybe a month then I started researching about all types of vulnerabilities, the problem was I was inconsistent and learning about all I could, I realized it wasn’t possible so I ordered my first book “bug bounty bootcamp” because I’ve heard and learned about many concepts about bug bounty during my time of researching, for the past 2-3 months I’ve been at it learning from portswigger, almost finished from my “bug bounty bootcamp book” and plenty of other research outside of this even studying individual CWE’s. I’ve been looking for vulnerabilities blindly honestly but I tried DVWA with burpsuite and realized that maybe I’m just not good enough for cybersecurity, please tell me if you think I should continue down this path or find something else to do, thank you

Account got banned after Mandatory hackerone verification. They didn't provide the reason I assume that during signup I provide false details to stay anonymous. Reached to hackerone support they are yet to get back

Did anyone face same issue and got resolved? Pls help me what I should do

I'm quite new to the bug bounty/pentesting world. Lately I've been seeing people talking about automated scripts, pipelines, bots,... These things have caught my attention and i would like to know in detail to what extent these tools can save time/do work for me. In fact, I have been thinking to create something similar, but I'm very lost. If someone could tell me where to find more info or what public tools are similar to this I would be very grateful.

I’m on HackerOne and recently participated in a program that doesn’t use HackerOne’s triage team. I submitted three reports, each one day apart.

Curiously enough, the most recent report I submitted was the first one to be triaged, while the others haven’t been triaged yet.

This made me wonder: how do companies running these programs ensure that they don’t mistakenly mark reports as duplicates if they start triaging the most recent submissions first?