# Privilege escalation from any user (including external) to gitlab admin when admin impersonates you

Impersonated user could see the admin's impersonation session in Active Sessions, set that cookie, and click Stop Impersonating to become admin.

- Payout: hidden
- Severity: critical
- Program: GitLab
- Found by: skavans
- Disclosed: 2020-08-26
- Write-up quality: 8/10
- Original: https://hackerone.com/reports/493324
- Library page: https://bugbountylibrary.com/r/h1%3A493324
- Tags: area:web domain:web impact:ato impact:privesc kind:bounty platform:hackerone sev:critical technique:source-review vuln:privilege-escalation

**Target:** GitLab web app session management / impersonation feature
**Root cause:** The impersonation session token is exposed to the impersonated user in the Active Sessions list, and 'Stop impersonating' restores the original admin session cookie from that same session context, letting the impersonated user inherit the admin cookie.
**Steps:**
1. As attacker, log in and revoke all sessions except current.
2. As admin in another browser, impersonate the attacker via admin users section.
3. As attacker, refresh Active Sessions; the admin's impersonation session appears.
4. Inspect the Revoke button to read the session ID of that session.
5. Visit GitLab index page as attacker, clear cookies.
6. In console run `document.cookie = "_gitlab_session=<copied_id>"`.
7. Refresh; you are now in the impersonated session.
8. Click 'Stop impersonating' to be logged in as admin.
**How found:** Researcher noticed that impersonation creates a new session visible in the impersonated user's Active Sessions list, and reasoned that 'Stop impersonating' restores the admin cookie from that session — so controlling the session means controlling the restore.
**Exploitation:** Attacker waits for admin to impersonate their account, harvests the impersonation session ID from the Active Sessions UI, sets it as their own `_gitlab_session` cookie, and triggers 'Stop impersonating' which restores the admin's real session cookie, granting full admin access.
**Insight:** When a feature temporarily swaps identities (impersonation, sudo mode, support access), check whether the temporary session is visible to the impersonated party and whether ending it restores the privileged identity's cookie — the restore path is the escalation.

