Skip to content

User remains access to update authored and assigned merge requests and issues after being removed from a project

HackerOne report #433047 by jobert on 2018-11-02:

To reproduce, follow these steps:

As user 1

  • sign in
  • create a private project
  • add a file to the repository
  • invite user 2 (maintainer)

As user 2

  • change the file in the repository
  • create a merge request

As user 1

  • remove user 2 from the project

As user 2

  • create a new, random project
  • create an issue
  • in bulk, close the issue and intercept the request, it'll look something like this:
POST /jobertabma/75e7/issues/bulk_update HTTP/1.1
Host: gitlab-instance
...

{"update":{"state_event":"close","assignee_ids":[null],"issuable_ids":"1","add_label_ids":[],"remove_label_ids":[]}}

In this request, substitute issues in the URL with merge_requests and the issuable_ids with a list (comma separated) with the merge request that was created by user 2 while they were part of the project. After the request has been submitted, go back to user 1 and observe that the merge request has been closed (or whatever state change was made in the request).

This vulnerability also works when the attacker (user 2) was the assignee on a merge request. It also works with issues.

Impact

A project member that has been removed from a private project remains control over the state, assignee, milestones, and labels of a merge request and issue.