Removed author of the merge request can still edit merge request’s approval rules using API

⚠️ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

HackerOne report #2980839 by theluci on 2025-02-07, assigned to GitLab Team:

Report | Attachments | How To Reproduce

Report

Hello, I hope you are doing well.

I found that the author of the merge request, removed from the project can still edit merge request’s approval rules using API even when the option isn’t available when using UI.

Vulnerability

According to docs, to override the merge request’s approval rules, You must have at least the Developer role in the project.

1feb-5.png

If the author of the merge request is removed from the project and tries to edit approval rules of the merge request, he can not do so using UI

1feb-6.png

Which is correct and as per the documentation.

However, the check isn’t ensured when using API.
That is, an author of the merge request, removed from the project can still override merge request’s approval rules using API contrary to documentation.

Steps to reproduce

  1. victim creates a public group victim-group and starts Ultimate trial.
  2. victim navigates to Manage --> Members,
  • victim invites victim-member as a Maintainer to victim-group
  • victim invites attacker as a Developer to victim-group
  1. victim creates a public project victim-project inside victim-group.
    (Initialize repository with a README)
  2. victim navigates to Settings --> Merge requests, scrolls down to Merge request approvals,
  • victim sets the Minimum required approvals to 2.
  • victim clicks Add approval rule and selects the following configuration,

6feb-1.png

6feb-2.png

  • victim selects the following configuration,

6feb-3.png

At this point, victim does not allow approval rules overriding and every merge request must be properly approved before being merged.

  1. attacker visits victim-project, creates a new branch another and makes some malicious changes.
  2. attacker creates a merge request from another branch to main.
  3. victim visits victim-project, navigates to Code --> Merge requests and selects the merge request. (Created in step 6)
  4. victim sets the merge request to auto-merge.

victim hopes to merge the request after the required approval criteria has been met but not yet as to investigate/review the code further.

  1. attacker visits victim-project, navigates to Code --> Merge requests, selects the merge request (Created in step 6) and marks it as Draft.
  2. victim visits victim-group, navigates to Manage --> Members and Removes attacker.
  3. victim visits victim-project, navigates to Settings --> Merge requests, scrolls down to Merge request approvals and uncheck Prevent editing approval rules in merge requests.

6feb-4.png

Now, victim allows approval rules overriding as only high role trustworthy members are in project and if required they can edit approval rules.

<------------------------------------Important----------------------------------------------->

These members already have enough permissions to visit Settings and edit approval rules if required, so giving them permission to override approval rules isn’t a security concern.
Please note that while attacker was a part of the project approval rules overriding were not allowed.

In a real-world scenario, approval rules overriding would only be allowed in a very trusting environment, where members may already have enough permission to edit approval rules from Setting if required.

Thus, for an attacker, not part of the project, to be able to edit a merge request’s approval rules is a grave security concern.

<----------------------------------------------------------------------------------------------->

  1. attacker visits https://gitlab.com/api/v4/projects/<victim-project-id>/approval_settings?target_branch=main
  • attacker notes the id of All Members

7feb-1.png

  1. attacker visits victim-project, navigates to Code --> Merge requests and selects the merge request. (Created in step 6)
  2. attacker clicks on Edit and unchecks Draft

6feb-5.png

  1. attacker clicks on Save changes but intercepts the request.
  2. attacker adds the following to the body of the request,
&merge_request%5Bapproval_rules_attributes%5D%5B%5D%5Bapproval_project_rule_id%5D=<ID_All_Members>&merge_request%5Bapproval_rules_attributes%5D%5B%5D%5Bapprovals_required%5D=0&merge_request%5Bapproval_rules_attributes%5D%5B%5D%5Bname%5D=&merge_request%5Bapproval_rules_attributes%5D%5B%5D%5Buser_ids%5D%5B%5D=&merge_request%5Bapproval_rules_attributes%5D%5B%5D%5Bgroup_ids%5D%5B%5D=

Please be sure to replace ID_All_Members with the ID noted in step 12.

<redacted>

  1. attacker forwards the request.

attacker is able to edit approval rules using API despite not being a part of the project.

  1. Merge request is merged.

POC

<redactec>

Output of checks

This bug happens on GitLab.com (Probably on instance too)

Impact

An author of the merge request, removed from the project can still override merge request’s approval rules using API (even though the option isn’t available when using UI) contrary to documentation, which in worst-case scenario may merge malicious changes to the protected branch.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section:

Edited by ADandy