**[HackerOne report #1113783](https://hackerone.com/reports/1113783)** by `vaib25vicky` on 2021-03-01, assigned to @dcouture: [Report](#report) | [Attachments](#attachments) | [How To Reproduce](#how-to-reproduce) ## Report ##### Summary Maintainer or owner can define protected environment and users who can access the protected environment. There are two issues present here 1. User removed from the project still have access to the protected environment 2. User who is removed and no longer part of the project then Maintainer can't remove him from the project settings > environment Because of this two issues User who is removed and no longer part of the project can still trigger deployment from the project environment page. ##### Steps to reproduce (Steps for Gitlab.com) * Create a public group * Protected environment is a Premium feature so you have to opt for trial. Go to your group > settings > billing and start your free trial `https://gitlab.com/groups/<namespace>/-/billings` * Create a public project inside the group named `test_project` * As maintainer invites a member to your project `test_project` with developer permission. lets say `user_foo` * As maintainer creates a `.gitlab-ci.yml` file in your project with below content ```yaml deploy: stage: deploy script: - echo "Deploy to production serverl" environment: name: production url: https://example.com ``` * As maintainer go to your project settings > CI/CD > Protected Environment and define a protected env such as `https://gitlab.com/<namespace>/test_project/-/settings/ci_cd` Environment - production Allowed to deploy - maintainer + user_foo  * In new incognito window or browser, login to the developer user `user_foo` account and go to the environment page `https://gitlab.com/<namespace>/test_project/-/environments` * Since, `user_foo` is allowed to access protected environment he can edit, stop, re-deploy .  * Go back to the maintainer account and removed `user_foo` from project * `user_foo` refresh the page or go again to `https://gitlab.com/<namespace>/test_project/-/environments` You will see that other options such as `stop` , `edit` are revoked but not `re-deploy`  **User can not only re-deploy latest but all the previous deployment too** * As user `user_foo` click on an old deployment and you will see the deployment pipeline will run and new deployment will be deployed   * You can see a new pipeline job `deploy` runs by going over `https://gitlab.com/<namespace>/test_project/-/jobs`  ##### Second issue is Maintainer can't removed the member from the protected environment Continuing the previous scenario * As maintainer go to the project > settings > CI/CD > protected environment `https://gitlab.com/<namespace>/test_project/-/settings/ci_cd` * Click on `Allowed to deploy` and unselect `user_foo` from the list  * Refresh the page, and again expand `protected environment`. You will see that user still not removed and there is no way maintainer can removed the user. ##### What is the current *bug* behavior? It is concluded that even after the user is removed * He can still have access to the deployment and re-deploy/trigger any deployment he wishes. * User can not only can re-deploy latest but all the previous deployment too. * Maintainer is not able to remove the user from the protected environment so user have access to protected environment all the time ##### What is the expected *correct* behavior? Gitlab should remove the user from protected environment list and revoked all his access too ##### Output of checks This bug happens on GitLab.com. I've not tested Gitlab instance but I'm confident that same vulnerability exists there too. #### Impact Protected Environment is an important feature which allows to restrict access and unexpected deployments to the environment. This vulnerability allows a malicious user who is not even the part of the project to trigger deployment to the protected environment and doing so may break a company or project current deployment and effects its user and data. ## Attachments **Warning:** Attachments received through HackerOne, please exercise caution! * [pe1.png](https://h1.sec.gitlab.net/a/92757583-9753-45a6-b7a2-25bd9c6ad4ac/pe1.png) * [pe2.png](https://h1.sec.gitlab.net/a/255164c5-7eef-4da4-b76c-6813c384e3f9/pe2.png) * [pe3.png](https://h1.sec.gitlab.net/a/738c04f0-7046-49c9-b51e-b2800d32ccae/pe3.png) * [pe4.png](https://h1.sec.gitlab.net/a/a504c0e6-377a-493b-935c-28c2e32bb552/pe4.png) * [pe5.png](https://h1.sec.gitlab.net/a/042d9d2c-8813-428c-8476-9e1aea8147ad/pe5.png) * [pe6.png](https://h1.sec.gitlab.net/a/0c6890e8-9acf-4964-b8bc-ff0412391026/pe6.png) * [pe7.png](https://h1.sec.gitlab.net/a/6f99c7d0-02cb-426e-ad12-292f7675a2ac/pe7.png) ## How To Reproduce Please add [reproducibility information] to this section: 1. Create a public group 1. Create a public project in that group 1. Create an environment named production 1. Setup a `.gitlab-ci.yml` 1. Invite a second user as `developer` 1. In CI/CD project settings create a protected environment for the `production` environment and allow the invited user to deploy 1. Remove the second user from the project and they'll still be able to redeploy from the `/-/environments` page [reproducibility information]: https://about.gitlab.com/handbook/engineering/security/#reproducibility-on-security-issues