August 27, 2026
Sign Out Everywhere Bypass: How I Found a Session Revocation Vulnerability in OAuth & Password…
Bismillāh ir-Raḥmān ir-Raḥīm.
By mhd101
3 min read
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 period and 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.