Skip to content

External user can rotate project token via POST /api/v4/projects/{projectId}/access_tokens/{tokenId}/rotate to gain new token with Internal access

⚠️ 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 #2888260 by aituglo on 2024-12-09, assigned to @ngeorge1:

Report | Attachments | How To Reproduce

Report

Summary

A user with external access can rotate a project token created by an internal user in order to access all the external projects and access.

Steps to reproduce

You will need two users, an internal ( simple user ) user who can create projects called INTERNAL and an external user called EXTERNAL.

With INTERNAL user:

  • Create a new private project, and invite EXTERNAL into it as a maintainer :

CleanShot_2024-12-09_at_10.23.52.png

  • Navigate to the settings of the project in access token and create a new token for the project with all the scope you want but mainly api and read_api :

CleanShot_2024-12-09_at_10.24.27.png

With EXTERNAL user:

  • Navigate to the project and go to the access token settings. You can rotate the token created by INTERNAL and use it with the gitlab api to access all the internal projects and clone them.

CleanShot_2024-12-09_at_10.28.05.png

  • You can now for instance make this request to access all the projects on the gitlab instance, including the internal ones.
GET /api/v4/projects HTTP/1.1  
Host: localhost:3000  
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:133.0) Gecko/20100101 Firefox/133.0  
Accept: application/json, text/plain, */*  
PRIVATE-TOKEN: glpat-***

CleanShot_2024-12-09_at_10.29.34.png

Impact

With this issue, an external user can now access all the internal repository and clone them, access them.

It can then leak important data. With the scope related to the access token, the user can also create new internal project, interact with them, post issues and so on.

Examples
What is the current bug behavior?

When an external user create an access token on a project, this token is related to a new bot user with the flag external enabled. It's not the case when the token is created by an internal user and then rotated by the external user.

What is the expected correct behavior?

If it's an external user that rotate the token, the bot user should get the external flag enabled.

Results of GitLab environment info
System information  
System:		  
Proxy:		no  
Current User:	aituglo  
Using RVM:	no  
Ruby Version:	3.2.4  
Gem Version:	3.5.23  
Bundler Version:2.5.11  
Rake Version:	13.0.6  
Redis Version:	7.0.14  
Sidekiq Version:7.2.4  
Go Version:	go1.23.2 darwin/arm64

GitLab information  
Version:	17.7.0-pre  
Revision:	3bfc0f5fa0a  
Directory:	/Users/aituglo/hacking/bb/gitlab/gdk/gitlab  
DB Adapter:	PostgreSQL  
DB Version:	14.9  
URL:		http://127.0.0.1:3000  
HTTP Clone URL:	http://127.0.0.1:3000/some-group/some-project.git  
SSH Clone URL:	ssh://git@127.0.0.1:2222/some-group/some-project.git  
Elasticsearch:	no  
Geo:		no  
Using LDAP:	no  
Using Omniauth:	yes  
Omniauth Providers: 

GitLab Shell  
Version:	14.39.0  
Repository storages:  
- default: 	unix:/Users/aituglo/hacking/bb/gitlab/gdk/praefect.socket  
GitLab Shell path:		/Users/aituglo/hacking/bb/gitlab/gdk/gitlab-shell

Gitaly  
- default Address: 	unix:/Users/aituglo/hacking/bb/gitlab/gdk/praefect.socket  
- default Version: 	17.5.0-rc1-338-gc808ff0c9  
- default Git Version: 	2.47.0

Impact

With this issue, an external user can now access all the internal repository and clone them, access them.

It can then leak important data. With the scope related to the access token, the user can also create new internal project, interact with them, post issues and so on.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: