# Impersonation session token exposure

Does an impersonation or support flow hand the impersonated user's session token to the caller, or trust a client-supplied session ID?

_Area: Web authentication and account takeover. Seen in 3 disclosed reports; one confirmed bounty: $6,000; latest 2026-07-01. Updated 2026-11-01._

## How it works
A feature that swaps identity (impersonation, support access, staging login, session attach) mints or reuses a session for the target principal. The assumption that breaks: that this session is only usable by the privileged operator. If the token is returned to, or visible to, the impersonated party — or if the server accepts a client-supplied session identifier without binding it to the caller — the lower-privileged party holds a credential for the higher-privileged identity. Ending the swap then restores the privileged session from that same context, completing the takeover.

## Where it shows up
- Impersonation/sudo/support flows that create a new session and list it in the target user's Active Sessions [E2](https://bugbountylibrary.com/r/h1%3A493324.md)
- "Stop impersonating" logic that restores the original cookie from the impersonation session context [E2](https://bugbountylibrary.com/r/h1%3A493324.md)
- RPC methods that enumerate attached session IDs without authentication [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-5qfp-32cf-69jh.md)
- Handlers accepting a client-supplied `session` field with no ownership check against the auth principal [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-5qfp-32cf-69jh.md)
- Staging/mirror hosts sharing a session store with production; a cookie minted on staging trusted by prod [E1](https://bugbountylibrary.com/r/blog%3Akamilonurozkaleli-com-posts-starbucks-singapore-account-takeover.md)
- Endpoints that associate a session with an account from an arbitrary email/identifier parameter [E1](https://bugbountylibrary.com/r/blog%3Akamilonurozkaleli-com-posts-starbucks-singapore-account-takeover.md)

## How to review
Identify every place a session token is created, listed, or accepted. The invariant: a session token must only be usable by, and visible to, the principal it was minted for; any client-supplied session identifier must be verified to belong to the caller's auth principal before use. Check: is the impersonation session shown to the impersonated user? Does ending impersonation restore a cookie from a context the impersonated user controls? Does the session-enumeration method require auth? Does `/rpc`-style input bind `session` to the caller? Do staging and production share a session store, and does an account-association endpoint verify ownership of the email?

## How finders spotted it
- Noticed impersonation creates a session visible in the impersonated user's Active Sessions, and reasoned that "Stop impersonating" restores the admin cookie from that session [E2](https://bugbountylibrary.com/r/h1%3A493324.md)
- Observed the `sessions` RPC exposed attached session UUIDs and that `/rpc` trusted client-supplied session IDs without binding them to the auth principal [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-5qfp-32cf-69jh.md)
- Saw a page loading from a third-party host, found a login directory there, hypothesized staging, and confirmed shared auth with a fresh production account [E1](https://bugbountylibrary.com/r/blog%3Akamilonurozkaleli-com-posts-starbucks-singapore-account-takeover.md)

## Variants seen
- Impersonation session exposed to impersonated user, restore-on-stop yields admin cookie [E2](https://bugbountylibrary.com/r/h1%3A493324.md)
- Unauthenticated session enumeration plus unbound client-supplied session ID [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-5qfp-32cf-69jh.md)
- Staging endpoint associates session with arbitrary email; staging cookie accepted by production [E1](https://bugbountylibrary.com/r/blog%3Akamilonurozkaleli-com-posts-starbucks-singapore-account-takeover.md)

## Impact and severity
Full account takeover: admin takeover from any user [E2](https://bugbountylibrary.com/r/h1%3A493324.md), anonymous hijack of root-level sessions giving administrative control and session invalidation [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-5qfp-32cf-69jh.md), and victim password reset via shared staging cookie [E1](https://bugbountylibrary.com/r/blog%3Akamilonurozkaleli-com-posts-starbucks-singapore-account-takeover.md). Impact rose with privilege of the impersonated principal and reach across environments; chaining staging environments bypassed a test-user limit and earned a bounty multiplier [E1](https://bugbountylibrary.com/r/blog%3Akamilonurozkaleli-com-posts-starbucks-singapore-account-takeover.md).

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Akamilonurozkaleli-com-posts-starbucks-singapore-account-takeover.md
- E2: https://bugbountylibrary.com/r/h1%3A493324.md
- E3: https://bugbountylibrary.com/r/ghsa%3AGHSA-5qfp-32cf-69jh.md