Summary of limited download archive unauthorized access of repositories on GitLab.com

Summary

From April 17, 2018 to April 24, 2018, a limited number of public and private repositories may have been inadvertently downloaded by unauthorized users on GitLab.com. GitLab user Lee Pugh notified us of this issue on April 23, 2018. The affected users represent 0.04 percent of our GitLab.com user base. While files generated by users would be unique for that repository, a recent change to support a use case to download the latest copy of the repository with the same filename inadvertently introduced this vulnerability.

This vulnerability affected GitLab.com users, and was mitigated as of April 23, 2018. None of the our on-prem users are affected by this vulnerability. We have notified the affected users via email, and are implementing a series of security enhancements to prevent such issues from happening again.

Accidental unauthorized access of download archives

From April 17, 2018 to April 24, 2018, a subset of GitLab.com users were potentially affected by a security vulnerability where a limited number of public and private repositories may have been inadvertently downloaded by unauthorized users.

Prior to v10.7.0, a unique hash value was always included in the request for the archive file to processed by Workhorse, the subsystem responsible for performing slower operations on Git repositories. This meant any file generated by the user would generally be unique for that repository. With the release of v10.7.0, the append_sha parameter was made optional. The motivation of the change was to support the use case where the latest copy of the repository could be downloaded with the same filename.

However, this introduced a problem - a repository download archive request without this parameter will return the ArchivePath value without a unique ID. As a result of this change, an archive request for a second project with the same name will point to the same archive file. This vulnerability was mitigated in production within hours of discovery by disabling feature flags controlling the caching behavior. The vulnerability has been patched in the latest Security Release.

Impact

There is no evidence of malicious activity for the accidental unauthorized access of download archives. However, the detailed audit logs for our log aggregator only cover part of the seven days in question. Potentially affected users have received email notifications accordingly. Although there is no evidence to suggest it happened, in the worst case, a private repository could have been accidentally downloaded.

Mitigations

Since the discovery, we have worked to investigate and mitigate all of these related security issues. We are continually improving our security processes and logging mechanisms to ensure that similar incidents will not occur again. These improvements include:

• Increase logging retention periods
• Fine-grain access controls to all logging infrastructure
• Add unit/integration tests to ensure consistent coding practices

If your project or account is potentially affected by this security issue, you will receive an email notification listing affected projects.

We apologize for the impact this issue has caused our users. GitLab takes your information and your data extremely seriously. We will learn from this incident and use it to improve upon our security even further.

In keeping with our company value of transparency we also believe in communicating about such incidents clearly and promptly. If you have any questions, please contact security@gitlab.com.