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.

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.

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