# Todos are not redacted when membership changes - Access to (confidential) issues and merge requests

GitLab failed to redact todos after a user's project role was downgraded, letting a Guest still read confidential issues and MRs via the todos API.

- Payout: hidden
- Severity: medium
- Program: GitLab
- Found by: vaib25vicky
- Disclosed: 2020-11-02
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/880863
- Library page: https://bugbountylibrary.com/r/h1%3A880863
- Tags: area:web domain:web impact:data-leak kind:bounty platform:hackerone sev:medium tech:rest technique:regression vuln:access-control vuln:info-disclosure

**Target:** GitLab todos API (/api/v4/todos)
**Root cause:** Todo redaction on permission change only triggers when a user is removed from the project, not when their access level is downgraded; the one-hour grace-period redaction job no longer fires for downgrades.
**Steps:**
1. Owner adds user with Repository access level.
2. User adds issues and MRs to their todo list.
3. Owner downgrades user to Guest.
4. Guest calls `curl --header "PRIVATE-TOKEN: <token>" https://gitlab.example.com/api/v4/todos` and still receives confidential issue/MR data.
**How found:** Regression of a previously fixed issue (#54349); researcher noticed todos were no longer redacted after the one-hour grace period and tested a role downgrade versus removal.
**Exploitation:** A downgraded Guest retains read access to confidential issues and merge requests through the todos API, bypassing the intended permission reduction.
**Insight:** When testing permission-change bugs, distinguish removal from downgrade: redaction/cleanup hooks often fire only on membership deletion, so test role transitions (higher to lower) separately against cached/derived resources like todos, notifications, and feeds.