Bypassing CODEOWNERS approval allowing to steal protected variables
:warning: **Please read [the process](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md) on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.**
**[HackerOne report #2295423](https://hackerone.com/reports/2295423)** by `ali_shehab` on 2023-12-22, assigned to `GitLab Team`:
[Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce)
## Report
##### Summary
Hi team hope you are well. There is something weird happening, that allows me to bypass CODEOWNERS approval of a file. This done by creating a branch through a merge request`ali` -> `main` and approve the mr by the CODEOWNER then deleting `ali` branch, creating branch `ali2` and add evil code to it, and create mr. Now create `ali` from `ali2` . Go back to the first mr, reopen and merge you will see that evil code was added although it was not approved.
##### Steps to reproduce
**As an owner:**
1. Create a new group and apply the ultimate trial to it
2. Create a new project in that group
3. Create a `CODEOWNERS` file with the following content
```
[Code Owners]
* [@]OWNER_USERNAME
```
4. Navigate to https://gitlab.com/GROUP/PROJECT/-/settings/repository, and do the following for the `main` branch:
- Toggle on code owner approval
- Allow developers and maintainers to merge
5. Invite a developer to the group
**As the developer:**
6. Create a new branch, add any change to any file, and create an MR from that branch to `main` - let's call that branch `test-1`
**As the owner:**
7. Approve that MR (the owner sees the changes, they're all safe and can be merged)
**As the developer:**
8. Delete `test-1` branch
9. Create a new branch call it `test-2`, and add "evil" code to the repository, create an MR with that change
10. Create a new branch called `test-1` from `test-2`
11. Navigate back to the MR approved by the owner, and open the mr and merge
12. Refresh the page, and verify that you can merge the MR
13. Merge that MR, and verify that the second MR (created in step 9) is also merged
14. Verify that the merged change is that introduced in the second MR which the owner didn't approve

#### Impact
Able to bypass codeowners approval which can lead to pass and evil code and steal protected enviroment.
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [Screen_Recording_2023-12-22_at_8.56.50___PM.mov](https://h1.sec.gitlab.net/a/b167cddf-4c13-4752-a1b5-7290e188fa1a/Screen_Recording_2023-12-22_at_8.56.50___PM.mov)
## How To Reproduce
Please add [reproducibility information] to this section:
1.
1.
1.
[reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues
issue