GitLab Vulnerabilities And Security Incidents: 2023 In Review
Tags: gitlab, git, devops, security
Published: 2024-03-14 11:06:16

We continue our series of DevOps incidents and failures. This time, we stopped our view on GitLab. What incidents made this secure service provider appear in Tech media in 2023?

Well, let’s jump at the topic and see what vulnerability flaws and threat incidents GitLab had to deal with to help its users protect their data.

![GitLab Status Information (Review of 2023)](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kel91f1j4kytohzf2v4t.jpg)

**DECEMBER 2023**
_GitLab Status info: 3 incidents_

**NOVEMBER 2023**
_GitLab Status info: 5 incidents_

**OCTOBER 2023**
_GitLab Status info: 6 incidents_

**SEPTEMBER 2023**
_GitLab Status info: 5 incidents_

## Critical  flaw detected in GitLab – users must update
Affecting all versions of GitLab Enterprise Edition (EE) from 13.12 to 16.2.7, and the GitLab Community Edition (CE) versions from 16.3 to 16.3.4, the detected critical flaw, CVE-2023-5009 ranked at CVSS score of 9.6 could allow a threat actor to run pipelines as an arbitrary user through the scheduled security scan policies.

The given vulnerability was a bypass of the CVE-2023-3932 security flaw, which GitLab resolved earlier in August 2023. Here is what GitLab says in [its advisory](https://about.gitlab.com/releases/2023/09/18/security-release-gitlab-16-3-4-released/): 

> “This was a bypass of CVE-2023-3932 showing additional impact. This is a critical severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 9.6). It is now mitigated in the latest release and is assigned CVE-2023-5009.”

If an attacker managed to exploit the vulnerability flaw, he could access sensitive data or use the elevated user permissions to run arbitrary code or make some changes to the source code on the system… both of which might have severe consequences and affect the user’s critical data.

[The Hacker News](https://thehackernews.com/2023/09/gitlab-releases-urgent-security-patches.html) / [Security Week](https://www.securityweek.com/gitlab-patches-critical-pipeline-execution-vulnerability/)

**AUGUST 2023**
_GitLab Status info: 10 incidents_

## Cyberattacks on GitLab platforms using binaries
In August GitLab fell victim to a highly skilled assault that not only undermined the service provider’s security but also made an innovative Proxyjacking scheme possible. According to the Sisdig Threat Research Team (TRT), the malicious actors in their financially motivated operation, dubbed LABRANT, used binaries written in Go and .NET to compromise the instances of the on-premise version of the GitLab CI/CD platform. Here is what the [Sysdig’s report](https://sysdig.com/blog/labrat-cryptojacking-proxyjacking-campaign/) says: 

> “The attacker utilized undetected signature-based tools, sophisticated and stealthy cross-platform malware, command and control (C2) tools which bypassed firewalls, and kernel-based rootkits to hide their presence.”
 
Initially, the attackers managed to gain access to the container using the CVE-2021-22205 vulnerability flaw (CVSS score of 10.0) which GitLab already remediated and patched in GitLab versions released on April 14, 2021. Then, once they accessed the server, the threat actors downloaded a malicious script from the C2 server. To hide and redirect connections to a password-protected web server, which hosted a malicious shell script, the hostile actors used a legitimate service, TryCloudflare. Thus, it was hard for the defenders to flag subdomains as malicious. What’s more, they used normal operations as well… How tricky…

The entire LABRANT operation could ultimately open the door for ransomware, data theft, and other follow-on attacks. Thus, [in its advisory GitLab](https://about.gitlab.com/blog/2021/11/04/action-needed-in-response-to-cve2021-22205/) urged its users to upgrade their self-managed public-facing GitLab instances to a fixed version as soon as possible. 

Moreover, here is the advice GitLab shared to The Hacker News:

> “Users impacted by CVE-2021-22205 should follow their organization’s Security Incident and Disaster Recovery processes to deprovision the compromised instance and restore the latest good working backup to a new GitLab instance”.

💡 **What is Proxyjacking? **

**Proxyjacking** is a malevolent technique in which a threat actor takes over its target’s proxy server and, as a result, can snoop on and alter the victim’s online activity and presence. 

[DevOps.com](https://devops.com/sysdig-identifies-cyberattacks-on-gilab-platforms-using-binaries/) /  [The Hacker News](https://thehackernews.com/2023/08/new-labrat-campaign-exploits-gitlab.html) / [TechNews](https://www.techbusinessnews.com.au/news/gitlab-exploited-to-launch-novel-proxyjacking-attack-sell-excess-bandwidth-for-cash/)

## GitLab patches critical RCE bug
A critical severity issue, identified as CVE-2022-2884 with a dangerous base score of 9.9 in CVSS, GitLab patched at the beginning of November. Using the vulnerability threat actors could launch several attacks against GitLab servers. As the company explained in [its advisory](https://about.gitlab.com/releases/2022/08/22/critical-security-release-gitlab-15-3-1-released/#Remote%20Command%20Execution%20via%20Github%20import), the vulnerability could allow _“an authenticated user to achieve remote code execution via the Import from GitHub API endpoint.”_

Thus, to address the issue found in GitLab CE/EE visions from 11.3.4 to 15.1.5, GitLab strongly recommended upgrading the vulnerable instances to the latest version as soon as possible. 

[The Daily Swig. Cybersecurity news and views](https://portswigger.net/daily-swig/gitlab-patches-rce-bug-in-github-import-function) / [HELP Net Security](https://www.helpnetsecurity.com/2022/08/24/cve-2022-2884/)

**JULY 2023**
_GitLab Status info: 5 incidents_

**JUNE 2023**
_GitLab Status info: 10 incidents_

## Critical account takeover flaw in GitLab is patched
On June 1st, GitLab released patches to address an account takeover issue discovered in GitLab Enterprise Edition. The severity issue was tracked as CVE-2022-1680 with a CVSS score of 9.9. According to GitLab, the issue was primarily caused by a bug in the open standard System for Cross-domain Identity Management (SCIM), which is available on Premium+ membership. 

Thus, by configuring the group SAML SSO, any owner of a Premium group can permit to invite arbitrary users via their email or username. They can then use SCIM to change those users’ email addresses to attacker-controlled ones, which would allow them to take over those accounts if there is no 2FA. What’s more, with the critical issue an attacker could “change the display name and username of the targeted account,” as GitLab explains in its [advisory](https://about.gitlab.com/releases/2022/06/01/critical-security-release-gitlab-15-0-1-released/). 

[Decipher. Security news that informs and inspires](https://duo.com/decipher/gitlab-patches-critical-account-takeover-flaw)

**MAY 2023**
_GitLab Status info: 6 incidents_

## GitLab security update addresses a critical vulnerability with the max CVSS score
On May 23, 2023, [GitLab released version 16.0.1](https://about.gitlab.com/releases/2023/05/23/critical-security-release-gitlab-16-0-1-released/) for GitLab Community Edition and Enterprise Edition with important security fixes, addressing a vulnerability flaw tracked as CVE-2023-2825 with the maximum CVSS score of 10. 

According to the GitLab advisory, _“an unauthenticated malicious user can use a path traversal vulnerability to read arbitrary files on the server when an attachment exists in a public project nested within at least five groups.” _

Thus, after releasing the update, GitLab strongly recommended that all the installations run 16.0.0. version was upgraded to the released version as soon as possible. 

[GridinSoft.blog](https://gridinsoft.com/blogs/gitlab-critical-vulnerability/)

**APRIL 2023**
_GitLab Status info: 8 incidents_

**MARCH 2023**
_GitLab Status info: 9 incidents_

## GitLab critical flaw could allow attackers to read arbitrary files & remotely execute code
According to Threat Post, a vulnerability flaw, which was found via the [HackerOne bug bounty platform](https://hackerone.com/reports/827052), was found in GitLab on March 23. The critical vulnerability is a path-traversal flaw that could permit a threat actor to read arbitrary files on the server that was running the app. Thus, an attacker could get access to tokens, configs, private data, and more. 

The vulnerability was specifically in GitLab’s UploadsRewriter function, which could be used to duplicate files. The vulnerability was already addressed and patched in GitLab version 12.9.1. Here is what [GitLab states](https://about.gitlab.com/releases/2020/03/26/security-release-12-dot-9-dot-1-released/): 

> “An SSRF issue was discovered in the project import note feature. This issue is now mitigated in the latest release and is assigned CVE-2020-10956.”

[Threat Post](https://threatpost.com/critical-gitlab-flaw-bounty-20k/155295/)

**FEBRUARY 2023**
_GitLab Status info: 4 incidents_

**JANUARY 2023**
_GitLab Status info: 5 incidents_

## What’s the best way to boost the security of your GitLab data in 2024?
GitLab is a highly secure Git platform that takes the security of its users seriously. It regularly patches vulnerabilities and has a clear communication of the threats it faces. 

However, GitLab, as any other service provider follows [the Shared Responsibility Model](https://gitprotect.io/blog/gitlab-shared-responsibility-model-a-guide-to-collaborative-security/). It means that GitLab and its users share their duties in protecting the data. How do you think who is responsible for your data? Yeap, you are. 

Thus, to stay piece of mind that your source code and metadata are safe you should keep up with security best practices, such as restricting and controlling access to your GitLab account, rotating personal access tokens, keeping your finger on the pulse, and updating your app as soon as the new version is released… especially if there are some vulns. Moreover, you shouldn’t forget about the zero-trust approach while building your CI/CD and [GitLab backup](https://gitprotect.io/gitlab.html), which is the final line of source code protection. With secure [GitLab backup best practices](https://gitprotect.io/blog/gitlab-backup-best-practices/) you will be able to eliminate any disruptions of your workflow continuity due to GitLab outages, your own infrastructure downtime, human errors, or ransomware attacks.

**USEFUL RESOURCES:**

**_Blog posts:_**
[GitLab backup and restore best practices](https://gitprotect.io/blog/gitlab-backup-best-practices/)
[GitLab restore and Disaster Recovery](https://gitprotect.io/blog/gitlab-restore-and-disaster-recovery-how-to-eliminate-data-loss/)
[Top 2023 Resources for the DevOps career roadmap](https://gitprotect.io/blog/top-2023-resources-for-the-devops-career-roadmap/)

_**E-books:**_
[GitLab backup guide](https://gitprotect.io/gitlab-backup-guide.html)

_**Success stories:**_
[SUE adopts GitProtect.io backups for the GitLab environment to guarantee its Disaster Recovery](https://gitprotect.io/case-study-sue.html)

✍️ Subscribe to [GitProtect DevSecOps X-Ray Newsletter](https://gitprotect.io/gitprotect-newsletter.html?utm_source=d&utm_medium=m) – your guide to the latest DevOps & security insights

🚀 Ensure compliant [DevOps backup and recovery with a 14-day free trial](https://gitprotect.io/sign-up.html?utm_source=d&utm_medium=m)

📅 Let’s discuss your needs and [see a live product tour](https://calendly.com/d/3s9-n9z-pgc/gitprotect-live-demo?month=2024-04&utm_source=d&utm_medium=m)