Branch and Tag Name Ambiguity Enables Malicious Code Distribution in GitLab Repositories.
HackerOne report #3124199 by st4nly0n on 2025-05-02, assigned to @greg:
Report | Attachments | How To Reproduce
Report
Description:
A malicious actor can exploit an ambiguity in GitLab by importing an external repository that contains a default branch with the same name as a tag. While GitLab normally prevents the creation of tags that conflict with the default branch name 
, this restriction is not enforced during the import of external repositories. As a result, GitLab’s web interface displays the seemingly harmless content of the default branch, but when a user downloads the repository using the Download Source Code option, they receive a different, maliciously altered version of the code.
This attack can be used not only to trick victims into downloading a modified version of the full source code but also to retrieve individual files that have been tampered with—even though the web interface shows them as safe. This inconsistency represents a serious integrity issue that can be abused to distribute malware in a stealthy and deceptive manner.
Steps To Reproduce:
Perform the steps as the attacking user
1. Create an empty repository on bitbucket.org with the main branch named main.
2. Clone the repository and navigate into it:
git clone <BITBUCKET_REPO>
cd <BITBUCKET_REPO> 3. Create a file named hello.sh with harmless content:
echo 'echo "hello world"' > hello.sh 4. Commit the changes and push to origin:
git add . &&\
git commit -m "Init" &&\
git push origin HEAD -f 5. Create a bracnh with the name hack:
git checkout -b hack 6. Modify the hello.sh file with your preferred payload:
### Example
echo 'cat /etc/passwd' > hello.sh 7. Commit the changes:
git add . &&\
git commit -m "Init" 8. Create a tag with the name main:
git tag main 9. Push the main tag:
git push origin --tags 10. From the web interface, create a new project using the Import project from option, then select Bitbucket Cloud and choose the repository created in step 1.
Perform the following steps as a victim user:
11. From GitLab's web interface, observe how the content of the hello.sh file is displayed harmlessly.
12. Download the repository and execute the hello.sh file.
As a result of the steps described above, the victim who trusted the seemingly harmless content of the hello.sh file displayed in GitLab's web interface was surprised when executing it, as it ran unexpected arbitrary commands.
Please refer to the following proof of concept video demonstrating this result.
poc.mp4
What is the current bug behavior?
When an external repository is imported into GitLab and contains both a default branch and a tag with the same name (e.g., main), GitLab fails to detect this conflict. The web interface displays the contents of the branch as expected, but when the user downloads the repository via the Download Source Code option (or downloads individual files), the content served corresponds to the tag instead of the branch. This leads to a mismatch between what the user sees in the UI and what they actually receive.
What is the expected correct behavior?
GitLab should ensure that the contents displayed in the web interface match exactly what is delivered when downloading the repository via Download Source Code or accessing individual files. Additionally, GitLab should enforce the same validation rules during repository import as it does during manual creation—specifically, it should reject imports that contain a default branch and a tag with the same name, or clearly prioritize one in a documented and secure manner. This would prevent ambiguity and ensure content integrity for end users.
Output of checks
This bug happens on GitLab.com
Impact
This behavior enables attackers to mislead users who rely on GitLab’s interface to verify code before downloading it. It allows the distribution of malicious scripts or binaries that are not visible in the displayed default branch, potentially compromising systems that trust and execute the downloaded content. This undermines the trust in GitLab as a secure code hosting and sharing platform.
Attachments
Warning: Attachments received through HackerOne, please exercise caution!
How To Reproduce
Please add reproducibility information to this section: