# "External status checks" can be accepted by users below developer access if the user is either author or assignee of the target merge request

GitLab external status checks could be approved by MR authors/assignees with only Guest access, letting non-members spoof passing checks on their own merge requests.

- Payout: hidden
- Severity: medium
- Program: GitLab
- Found by: joaxcar
- Disclosed: 2022-06-08
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/1375393
- Library page: https://bugbountylibrary.com/r/h1%3A1375393
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:medium tech:rest technique:source-review vuln:access-control vuln:auth-bypass vuln:business-logic

**Target:** GitLab merge request external status check API
**Root cause:** The status_check_responses endpoint authorizes via :approve_merge_request, which is enabled for anyone with :update_merge_request; issuable_policy grants :update_merge_request to Guest users who are author or assignee of the MR.
**Steps:**
1. Create Ultimate project as owner01, enable external status check in MR settings.
2. As guest01 (non-member), fork project, push branch, open MR against upstream project.
3. Create PAT for guest01; GET `/api/v4/projects/<PID>/merge_requests/<IID>/status_checks` to obtain CHECK_ID.
4. POST `/api/v4/projects/<PID>/merge_requests/<IID>/status_check_responses?sha=a&external_status_check_id=<CHECK_ID>` to learn required SHA.
5. Repeat POST with returned SHA to mark the external status check as passed.
**How found:** Read the endpoint's authorization call `find_merge_request_with_access(..., :approve_merge_request)`, traced the policy chain in merge_request_policy.rb and issuable_policy.rb, and noticed :update_merge_request is granted to Guest authors/assignees, contradicting the unit tests' developer-only assumption.
**Exploitation:** A non-member Guest forks a public project, opens an MR, and uses their own PAT to POST status_check_responses for that MR, marking the external status check green so reviewers believe CI/security checks passed.
**Escalation:** Also works for demoted Reporter users on private projects, and (chained with report 1375376) for demoted Guest users who cannot even view the MR.
**Insight:** When an endpoint gates on a derived permission like :approve_merge_request, trace its policy enablement chain — it may inherit from broader rules (e.g. :update_merge_request granted to Guest authors/assignees) that silently widen access beyond the intended role.