When Changing an Email Isn’t Enough: Discovering a Persistent Account Takeover and Session Leakage…

Introduction

As a bug bounty hunter and web security researcher, I always pay close attention to account management features. While many researchers focus primarily on authentication endpoints, sensitive account settings often reveal equally interesting security issues.

During a routine assessment of a prominent AI Service Platform, I decided to review how the application handled email changes for accounts created via Google Single Sign-On (SSO). What started as a standard check uncovered a critical flaw in both OAuth identity binding and session management, allowing persistent Account Takeover (ATO).

Following the Flow & The Critical Discovery

The target account was originally registered using Continue with Google (attacker@gmail.com).

While testing the email change functionality to update it to a different address (victim-private@proton.me), I intercepted the HTTP traffic and noticed two severe anomalies:

1. Session ID Leakage: Upon successfully changing the email, the application's response leaked a valid Session ID.

2.Improper Session Invalidation: The old session established prior to the sensitive email change was not invalidated by the server.

3.To turn this into a full exploitation vector, I attempted to replay and modify login requests in an unauthenticated state.

The Core Logic Flaw:

When attempting a normal login sequence after the email change without the leaked Session ID, the application throws an error stating that no account exists under that email. However, during a fresh login sequence, a standard request does not inherently contain a session token. By manually manipulating the request and injecting the leaked/old Session ID into the headers/cookies, the application's backend blindly maps the session to the original identity. The application accepted it—completely bypassing the authentication check and maintaining active, full access to the account.

Furthermore, the trust relationship with the original Google identity had not been re-evaluated or unlinked after the email change.

Steps to Reproduce

1. Initial Setup: Register a new account using Google SSO with the original email: attacker@gmail.com.

2.Email Modification: Navigate to Account Settings and update the email to victim-private@proton.me.

3.Intercepting Traffic: Analyze the HTTP response of the email change request; observe that a valid Session ID is explicitly leaked in the response data.

3.Verifying the Blind Login (Without Session ID): Open a completely separate, unauthenticated browser session (Incognito mode). Attempt a standard login using the old email. The server returns an error: Account does not exist.

4.Session Injected Hijacking (With Session ID): Intercept the login request. Since standard login requests do not contain session states, manually inject the leaked, older Session ID into the request.

5.Session Hijacking Success: The application successfully processes the request and authenticates the session, meaning the historical session remained active and fully usable despite a critical ownership change.

6.Testing OAuth Persistence: In another clean incognito window, click Continue with Google and authenticate using the original Google account (attacker@gmail.com).

7.SSO Bypassing Success: Authentication succeeds instantly without any re-verification. You land on the exact same internal account (now linked to the ProtonMail address).

Verification & Proof of Concept (PoC)

To confirm both the active OAuth path and the hijacked session were operating on the exact same underlying identity:

• I modified the account's display name from the hijacked/Google SSO session.
• The changes immediately reflected on the owner's session (victim-private@proton.me) in real-time, confirming full concurrent read/write access.

Security Impact

An attacker who temporarily gains access or controls the initial registration state can maintain indefinite, invisible access to the victim's account. Because the access relies on a persistent OAuth binding and an uninvalidated token/session state leaked during the flow, traditional remediation like a password reset will completely fail to evict the attacker.

Disclosure Timeline

• Triaged: Acknowledged and triaged by the vendor's security team

• Connect With Me

LinkedIn

https://www.linkedin.com/in/ziad-atef-180839319

Facebook

https://www.facebook.com/share/191MFMv9Cm/?mibextid=wwXIfr

Thank you for reading, and stay tuned for more write-ups on web application security, authentication, OAuth, and bug bounty research.