# A deactivated user can access data through GraphQL

Deactivated GitLab users could still query and mutate via GraphQL because the endpoint checked only api scope, not the deactivated policy enforced on REST.

- Payout: hidden
- Severity: medium
- Program: GitLab
- Found by: joaxcar
- Disclosed: 2021-08-30
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1192460
- Library page: https://bugbountylibrary.com/r/h1%3A1192460
- Tags: area:web3 domain:web impact:integrity kind:bounty platform:hackerone sev:medium tech:graphql technique:source-review vuln:access-control vuln:auth-bypass

**Target:** GraphQL API endpoint (/api/graphql)
**Root cause:** Global policy prevents :access_api for deactivated users, but the GraphQL controller authorizes only on api scope, so the deactivated rule is never applied.
**Steps:**
1. Login as admin, create a user, deactivate it, create an API token for it
2. Send `curl 'https://gitlab/api/graphql' -H 'Authorization: Bearer <TOKEN>' --data '{"query":"{ currentUser{id} }"}'`
3. Observe data returned while REST `/api/v4/user` returns 403 deactivated
4. On <=13.11.1, add user to project via admin token then run `mutation { labelCreate(input:{title:"deactivated", projectPath:"test1/test1"}){ label{ id } } }` with deactivated token
**How found:** Reading the 13.11.2 changelog, noticed global_policy.rb restricts deactivated users from :access_api but allows :log_in; hypothesized GraphQL only checks api scope and confirmed by comparing REST 403 vs GraphQL success.
**Exploitation:** Attacker holding a token from a deactivated account (or admin creating deactivated service accounts) issues GraphQL queries/mutations; on pre-13.11.2 instances mutations like labelCreate succeed, allowing data access and writes without reactivation.
**Insight:** When a policy denies a coarse permission like :access_api, check every alternate API surface (GraphQL, websocket, git-over-http) for its own authorization path that may only check token scope.