The State of GitLab Threat Landscape – 2024 In Review
Last Updated on January 30, 2025
Let’s move on with our research on the DevOps threat landscape in 2024. Let’s see which security incidents and vulnerabilities GiLab users faced in the previous year.
In 2023, GitLab reported 76 incidents on their Status page, this year the number of incidents grew by almost 21% and compiled 96 incidents in total.
DECEMBER
GitLab Status info: 10 issues
🚨 Incidents that had a major impact – 7 incidents
⌛ Total time of partial service disruption – 130 hours 13 minutes
⚠️ Incidents that had a minor impact – 2 incidents
⌛ Total time of degraded performance – 17 hours 44 minutes
🔓 Security issue – 1 incidents
⌛ Total time of the security issue – 3848 hours 5 minutes
In December, GitLab faced 10 incidents, including 7 with a major impact, resulting in over 130 hours of partial service disruption.
Users might encounter intermittent errors, timeouts, and disruptions in CI/CD services, Git operations, and website functionality across multiple locations. The most significant incident, lasting 75 hours and 2 minutes, involved intermittent timeouts for requests from some Utah IP addresses.
Another major incident, spanning 26 hours and 16 minutes, caused errors across GitLab.com, affecting websites, pages, and background processing. Other disruptions included CI/CD runner failures and GitLab Duo chat issues.
NOVEMBER
GitLab Status info: total 8 incidents
⚡ Incidents that had a critical impact – 1 incident
⌛ Total time of service disruption – 1 hour
🚨 Incidents that had a major impact – 2 incidents
⌛ Total time of partial service disruption – 33 hours 17 min
⚠️ Incidents that had a minor impact – 3 incidents
⌛ Total time of degraded performance – 18 hours 46 minutes
🛠️ Planned Maintenance – 2 incidents
⌛ Total time of planned maintenance – 66 hours
GitLab users experienced 8 incidents, including a critical one that caused customer portal disruption for an hour.
Also, there were 2 major incidents that resulted in partial service disruptions, totaling over 33 hours and impacting the Jira Cloud app installation and the group API.
Other three minor incidents led to degraded performance for nearly 19 hours, affecting features like merge requests, user preferences, and Duo Chat.
GitLab vulnerability exploited in major Byte Federal cyberattack
The personal information of around 58K customers of Byte Federal, a leading Bitcoin ATM operator in the USA, was exposed by cybercriminals.
On November 18, 2024, Byte Federal’s security team discovered that hackers used a GitLab security flaw to breach the company. The hack exposed personal information, including names, dates of birth, residential addresses, phone numbers and email addresses, Social Security Numbers, transaction histories, photos, etc.
To address the issue the company promptly secured its systems and isolated the threat actor, who managed to access one of Byte Federal’s servers. Though the exact nature of the GitLab vulnerability the attackers used wasn’t identified, the organization conducted a complete reset of all its customers’ accounts, revoked access tokens, and updated internal passwords.
Also, Byte Federal urged all the affected customers to be attentive to any suspicious activity and report to the authorities in any case of fraudulent incidents.
The total of six security flaws, GitLab developers patched to protect GitLab CE/EE users in November. Among them, there were vulnerabilities of medium severity and one of a high severity level – 8.5 of 10. Using the vulnerability, tracked as CVE-2024-9693, an attacker could get unauthorized access to the Kubernetes agent in a cluster in some specific configurations.
Among less severe security flaws that were patched, were:
- CVE-2024-7404 with a CVSS score of 6.8, which allowed the hacker to gain full API access via the device OAth flow.
- DoS issue with the CVSS score of 6.5 which could take place upon importing maliciously crafted content via Fogbugz importer.
- CVE-2024-8648, with a severity of 6.1, that could permit the threat actor to inject malicious JavaScript code into the Analytics Dashboards via a specifically created URL.
- CVE-2024-8180 with a CVSS score of 5.4 – the HTML injection in this vulnerability might lead to XSS on the self-hosted instances.
- CVE-2024-10240 with a CVSS score of 5.3 which allowed an unauthorized user under some specific circumstances to read some info about an MR in private projects.
GitLab advised its users to update their GitLab Community Edition and Enterprise Edition to mitigate the risks that the mentioned security flaws could expose.
OCTOBER
GitLab Status info: total 9 incidents
⚡ Incidents that had a critical impact – 1 incident
⌛ Total time of service disruption – 11 hours 23 minutes
🚨 Incidents that had a major impact – 6 incidents
⌛ Total time of partial service disruption – 83 hours 49 minutes
⚠️ Incidents that had a minor impact – 1 incident
⌛ Total time of degraded performance – 1 hour 15 minutes
🛠️ Planned Maintenance – 2 incidents
⌛ Total time of planned maintenance – 77 hours
There were 9 incidents of different impact that the GitLab had to deal with in October. One of them, the critical one, lasted for roughly 11 hours and affected pipelines using SaaS Runners that were stuck on pending status.
Other 6 less major incidents caused partial disruptions totaling 80+ hours and impacting areas such as pipeline processing, self-managed runners, and Sidekiq job delays.
The rest of the minor incidents didn’t have much impact on GitLab service operation for GitLab users.
Critical arbitrary branch execution flaw in GitLab
Multiple security flaws were threatening GitLab Community Edition and Enterprise Edition users that the service provider successfully addressed in November 2024. There were 8 vulnerabilities, 5 of which were of high or critical severity.
The security flaw tracked as CVE-2024-9164 with a CVSS score of 9.6 might permit unauthorized users to run Continuous Integration and Continuous Delivery pipelines on any branch of a repo.
Another high severity vuln, tracked as CVE-2024-8970 with the CVSS score of 8.2, could permit the threat actor to trigger a CI/CD pipeline as another user.
Among other security flaws that GitLab addressed were:
- CVE-2024-8977 the CVSS score of which is 8.2 – the SSRF vulnerability in the Analytics Dashboards which could leave users unsafe to SSRF attacks.
- CVE-2024-9631 with a CVSS score of 7.5, which could lead to slowing down the viewing diffs of MR with conflicts.
- CVE-2024-6530 with a severity score of 7.3, which is an HTML injection vulnerability in the OAuth page permitting cross-site scripting when a user tries to authorize through OAuth.
- CVE-2024-9623 with a CVSS score of 4.9 that permits deploying keys for pushing to the archived repository.
- CVE-2024-5005, the severity score of which is 4.3, using which unauthorized users are able to disclose project templates via the API.
- CVE-2024-9596, with a low severity of 3.7, which could permit the bad actor to identify the GitLab version number of the GitLab instance.
GitLab “strongly” recommended its users to update the affected installations to make sure that their data is safe.
Bleeping Computer / The Hacker News
SEPTEMBER
GitLab Status info: total 17 incidents
⚡ Incidents that had a critical impact – 2 incidents
⌛ Total time of service disruption – 1 hour 28 minutes
🚨 Incidents that had a major impact – 3 incidents
⌛ Total time of partial service disruption – 25 hours 13 minutes
⚠️ Incidents that had a minor impact – 4 incidents
⌛ Total time of degraded performance – 270 hours 1 minute
⚙️ Operational issues – 5 incidents
⌛ Total time of operational issues – 122 hours 44 min
🛠️ Planned Maintenance – 3 incidents
⌛ Total time of planned maintenance – 74 hours
In September, GitLab experienced 17 incidents with different impact levels. Two incidents recognized by GitLab as critical, lasting for more than an hour in total, resulted in connectivity issues across multiple GitLab services and downtime of the Customer Portal.
Other 3 less severe incidents caused partial service disruptions, totaling 25+ hours, affected APIs, Git operations, and project accessibility. Four minor incidents led to degraded performance for a combined 270 hours, with the longest issue involving errors with the “View job currently using resource” button.
Authentification Bypass Bug is threatening GitLab CE and EE users
A critical authentication bypass vulnerability with a CVSS score of 10 (out of 10!) was patched in GitLab Community Edition (CE) and Enterprise Edition (EE). The security flaw tracked as CVE-2024-45409 was found in the ruby-saml library. Caused by improper signature verification of SAML responses, the vulnerability could allow attackers to log in as arbitrary users. The issue also affects omniauth-saml, which has been updated to version 2.2.1, while GitLab has patched multiple versions, including 17.3.3 and 16.11.10.
“An unauthenticated attacker with access to any signed SAML document (by the IdP) can thus forge a SAML Response/Assertion with arbitrary content… This would allow the attacker to log in as arbitrary user within the vulnerable systems,” states the security advisory.
To mitigate risks, GitLab recommends enabling two-factor authentication (2FA) and disallowing SAML two-factor bypass. While there is no confirmation of active exploitation, GitLab has provided indicators of potential abuse, such as specific SAML-related log events.
This update comes as the U.S. CISA adds new vulnerabilities, including a critical flaw in Apache HugeGraph-Server (CVE-2024-27348), to its Known Exploited Vulnerabilities catalog, urging agencies to have remediated them by October 9, 2024.
The Hacker News / Help Net Security / Dark Reading
AUGUST
GitLab Status info: total 6 incidents
🚨 Incidents that had a major impact – 4 incidents
⌛ Total time of partial service disruption – 50 hours 27 minutes
⚠️ Incidents that had a minor impact – 1 incident
⌛ Total time of degraded performance – 1 hour 22 minutes
⚙️ Operational issues – 1 incident
⌛ Total time of operational issues – 3 hours 32 minutes
In August, GitLab experienced six incidents, including four major ones with a total partial service disruption time of about 50 hours. The most significant incident lasted around 27 hours – during that time GitLab users might have had some issues in the documentation search. Other issues included CI/CD token allowlist failures and Duo AI feature malfunctions.
Critical pipeline execution vulnerability is patched – urgent update needed
Seventeen security vulnerabilities, including 4 high-severity, 11 medium-severity, and 2 of low-severity, were detected and patched by the GitLab DevOps team in August. The most critical issue, tracked as CVE-2024-6678 and a CVSS score of 9.9, might allow an attacker to run pipeline jobs as an arbitrary user.
Let’s not forget that GitLab pipelines, which are part of GitLab CI/CD, are automated workflows that DevOps use to build, test, and deploy their code. If a hacker gains access to them, it might lead to data loss.
In its alert, GitLab warns that “An issue has been discovered in GitLab EE affecting all versions starting from 11.1 before 17.1.7, 17.2 before 17.2.5, and 17.3 before 17.3.2.”
However, there was no evidence of active exploitation of this vulnerability, GitLab recommended its users update their GitLab instances as soon as possible.
The Hacker News / Bleeping computer
JULY
GitLab Status info: a total of 12 incidents
⚡ Incidents that had a critical impact – 2 incidents
⌛ Total time of service disruption – 783 hours 9 minutes
🚨 Incidents that had a major impact – 5 incidents
⌛ Total time of partial service disruption – 74 hours 54 minutes
⚠️ Incidents that had a minor impact – 2 incidents
⌛ Total time of degraded performance – 22 hours 53 minutes
⚙️ Operational issues – 3 incidents
⌛ Total time of operational issues – 20 hours 8 minutes
GitLab reported 12 incidents, including 2 critical ones totaling over 783 hours of disruption. The most significant issue lasted from June 6 to July 8, impacting bulk import functionality for nearly 779 hours. Another critical incident on July 11 caused a 4-hour global unavailability of core GitLab services for some users, affecting numerous components.
Also, there were five major partial disruptions totaling around 75, including prolonged issues with package manifests and merge requests. Minor performance degradation occurred in two incidents, lasting 22+ hours, primarily affecting repository and package access.
July brought the GitLab’s release of updates for 6 detected security flaws, including a critical vulnerability CVE-2024-6385 with a CVSS score of 9.6 out of 10 possible.
“We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible,” states GitLab’s advisory.
This bug, affecting GitLab CE/EE versions 15.8 to 17.1, allows attackers to execute pipeline jobs as arbitrary users under specific conditions. The flaw highlights ongoing risks, as similar vulnerabilities in June and August with around the same critical severity score were patched.
Bleeping Computer / The Hacker News / Security Week
JUNE
GitLab Status info: a total of 5 incidents
🚨 Incidents that had a major impact – 2 incidents
⌛ Total time of partial service disruption – 52 hours 6 minutes
⚠️ Incidents that had a minor impact – 2 incidents
⌛ Total time of degraded performance – 3 hours 45 minutes
⚙️ Operational issues – 1 incident (started in May)
⌛ Total time of operational issues – 845 hours 36 min
In June, GitLab experienced 5 incidents, including two major ones that led to partial service disruption that lasted in total for over 52 hours – more than a working week (over 6 days!).
A hacker can access and run the GitLab CI/CD pipeline of any GitLab user due to a bug
GitLab has released security updates addressing 14 vulnerabilities, including a critical flaw, CVE-2024-5655, that could allow an attacker to run CI/CD pipelines as another user. We’ve already mentioned previously in this blog that it was the third similar vulnerability that GitLab faced in 2024.
The case was reported to GitLab through its HackerOne bug bounty program. This vulnerability, rated 9.6 out of a maximum of 10 on the CVSS scale, impacts versions 17.1 prior to 17.1.1, 17.0 prior to 17.0.3, and 15.8 prior to 16.11.5 in both the Community and Enterprise Editions.
According to GitLab, the hosting service “we have not found evidence of abuse of this vulnerability on the platforms managed by GitLab, including GitLab.com and GitLab Dedicated instances.”
However, GitLab urgently advises its users to update their GitLab instances. The updates, available in versions 17.1.1, 17.0.3, and 16.11.5, introduce two breaking changes: GraphQL authentication using CI_JOB_TOKEN is now disabled by default, and pipelines no longer run automatically after a merge request’s target branch is merged.
Additional high-severity flaws include CVE-2024-4901 (stored XSS vulnerability, CVSS 8.7), CVE-2024-4994 (CSRF in GraphQL API, CVSS 8.1), CVE-2024-6323 (authorization issue in global search, CVSS 7.5), and CVE-2024-2177 (cross-window forgery in OAuth authentication, CVSS 6.8). These vulnerabilities could lead to unauthorized actions, sensitive data leakage, and exploitation via malicious payloads.
MAY
GitLab Status info: a total of 3 incidents
🚨 Incidents that had a major impact – 2 incidents
⌛ Total time of partial service disruption – 4 hours 19 min
⚠️ Incidents that had a minor impact – 1 incident
⌛ Total time of degraded performance – 1 hour 7 minutes
In May, GitLab reported 3 incidents including 2 issues of partial service disruptions totaling over 4 hours. These incidents impacted the API, website, and CI\CD services.
Hackers can take over GitLab accounts exploiting high-severity vulnerability
A high-severity XSS vulnerability, tracked as CVE-2024-4835, in the VS Code editor (Web IDE) that could allow unauthenticated attackers to take over user accounts by tricking users into interacting with malicious pages was patched by GitLab developers. Due to the absence of authentication necessity, user interaction increases the attack’s complexity.
This vulnerability, as well as other six medium-severity flaws, was addressed in versions 17.0.1, 16.11.3, and 16.10.6 of GitLab Community Edition (CE) and Enterprise Edition (EE).
Other important-to-mention medium-severity issues include a CSRF vulnerability via the Kubernetes Agent Server (CVE-2023-7045) and a denial-of-service bug (CVE-2024-2874) that could disrupt loading GitLab web resources.
GitLab strongly recommended upgrading to the described patched versions immediately as the updates aimed to enhance security and protect users from potential exploitation.
Severe GitLab password reset vulnerability is actively exploited by attackers
The U.S. Cybersecurity and Infrastructure Security Agency warned about GitLab’s critical vulnerability, tracked as CVE-2023-7028, to its Known Exploited Vulnerabilities (KEV) catalog due to active exploitation in the wild.
The flaw, with the highest CVSS score possible of 10, was introduced in GitLab version 16.1.0, allows an attacker to take over GitLab users’ account by sending password reset emails to unverified email addresses. Although users with two-factor authentication are less vulnerable to account takeover, their accounts can still be subjected to password resets.
By exploiting this vulnerability, attackers get the possibility to steal GitLab users’ sensitive information, credentials, and malicious code insertion in source code repositories, potentially resulting in supply chain attacks. Moreover, attackers may embed malware in CI/CD pipelines to exfiltrate data or create backdoors, undermining system integrity and security.
The issue has been patched in GitLab versions 16.5.6, 16.6.4, 16.7.2, and earlier versions via backports. Federal agencies are mandated to have applied these fixes by May 22, 2024, to protect against ongoing exploitation.
APRIL
GitLab Status info: a total of 10 incidents
⚡ Incidents that had a critical impact – 1 incident
⌛ Total time of service disruption – 1 hour 30 minutes
🚨 Incidents that had a major impact – 7 incidents
⌛ Total time of partial service disruption – 50 hours 34 minutes
⚠️ Incidents that had a minor impact – 2 incidents
⌛ Total time of degraded performance – 43 hours 59 minutes
In April, GitLab reported 10 incidents, including one highly severe service disruption that lasted for over an hour. Also, there were 7 partialservice disruptions that accounted for a total of 50+ hours, with issues such as stuck merge requests, SaaS runners failing, and errors managing Kubernetes agents.
The other 2 incidents caused degraded performance, totaling about 44 hours, with notable issues like errors in downstream pipelines and dependency proxy failures. The disruptions affected key components, including the website, API, CI/CD runners, and the customer portal, all hosted on Google Compute Engine.
Hackers abuse GitLab to spread malware
In April, Bleeping Computer experts investigated and reported how threat actors can abuse GitHub comments to push malware. However, later after checking GitLab, it turned out that the service provider tends to the same issue – the git hosting service is susceptible to abuse of its comments feature, allowing threat actors to upload malicious files that appear to be hosted on legitimate repositories.
This exploit enables attackers to upload files, including malware, to GitLab’s CDN under URLs resembling official project repositories. The links remain live even if the associated comment is never posted or is deleted, making them a potential tool for deception.
For example, files uploaded using this flaw can mimic releases from trusted open-source projects like Inkscape and Wireshark, misleading users into downloading counterfeit software.
Source: Bleeping Computer
Though GitLab requires its users to sign in before they upload the files, it can’t prevent bad actors from uploading malicious files.
“Since virtually every software company uses GitHub or GitLab, this flaw enable allow threat actors to develop extraordinary crafty and trustworthy lures,” states Bleeping Computer.
Bleeping Computer / GridinSoft blog
JsOutProx malware attacks financial institutions in APAC and MENA abusing GitLab
In early April, Resecurity reported that a new version of JSOutProx, a sophisticated attack framework targeting financial organizations in the APAC and MENA regions, had been detected.
💡 JSOutProx uses JavaScript and .NET, leveraging .NET (de)serialization to interact with JavaScript modules on victims’ systems and load plugins for further malicious activities. Initially linked to SOLAR SPIDER’s phishing campaigns since 2019, the malware has been used in attacks involving fake SWIFT and Moneygram notifications to target banking customers.
In 2024 a few incidents involving a system integrator in Saudi Arabia and financial customers targeted through impersonation schemes using the “mike.will@my[.]com” took place.
GitLab? On March 27th, 2024 Resecurity researchers noticed a new malware sample on GitLab (before the attackers used GitHub in their malicious schemes):
“The actor registered multiple accounts on GitLab around March 25, 2024, and used them to deploy repositories containing malicious payloads,” is stated in the Resecurity Report.
Source: Resecurity blog
After the successful delivery of the malicious code, the thread actor removes the GitLab repo and creates an absolutely new one. It may be related to the fact that the hacker exploits multiple malicious payloads and adapts to its target.
These two facts – the discovery of the new version of JSOutProx and GitLab’s abuse it the malicious schemes – prove that JSOutProx is still an evolving and significant threat, especially when it comes to financial institutions.
Cyber Security News / Security Affairs
MARCH
GitLab Status info: 6 incidents
🚨 Incidents that had a major impact – 2 incidents
⌛ Total time of partial service disruption – 66 hours 57 hours
⚠️ Incidents that had a minor impact – 4 incidents
⌛ Total time of degraded performance – 41 hours 19 minutes
In March, GitLab communicated in its GitLab Satus 6 incidents. There were 2 major issues that lasted a total of around 67 hours and 4 minor incidents that caused degraded performance for GitLab users for over 41 hours. Affected components included the website, API, CI/CD runners, and background processing, with services hosted on Google Compute Engine, AWS, and Zendesk.
GitLab security flaw allows threat actors to inject malicious scripts
In its March patch release, GitLab addressed critical vulnerabilities that could permit attackers to inject malicious scripts and cause the DoS attack.
Discovered in GitLab Community Edition and Enterprise Edition, a Stored Cross-Site Scripting (XSS) vulnerability, – the CVE-2023-6371 security flaw with a severity of 8.7 – could allow the attacker to perform arbitrary actions on behalf of the affected users by injecting a crafted playboad into a wiki page. The vulnerability affected all versions of GitLab CE/EE prior to 16.8.5, from 16.9 before 16.9.3, and from 16.10 to 16.10.1.
Another security flaw that GitLab had to address in March was DoS using crafted emojis. Tracked as CVE-2024-2818 with the CVSS of 4.3, the flaw could permit the threat actors to trigger a denial of service by using the maliciously crafted description parameter for labels.
To improve GitLab users’ security posture, GitLab strongly advised them to update the affected versions.
FEBRUARY
GitLab Status info: 6 incidents
🚨 Incidents that had a major impact – 2 incidents
⌛ Total time of partial service disruption: 1 hour 54 minutes
⚠️ Incidents that had a minor impact – 3 incidents
⌛ Total time of degraded performance – 18 hours 6 minutes
🛠️ Planned Maintenance – 1 incident
⌛ Total time of planned maintenance – 1 hour
GitLab experienced 6 incidents of different impacts that might influence GitLab users in February. Those events included 2 major ones causing about 2 hours of partial service disruption, both involving intermittent job failures with GitLab SaaS runners, and 3 minor incidents which led to 18+ hours of degraded performance, primarily affecting the API and website components.
Discovered exposed API secrets could impact major tech tokens
The security research team at Escape discovered over 18K vulnerable API secrets after scanning 189M+ URLs. Of the disclosed secrets, 41% were highly critical, which means that they could lead to financial risks for companies. Among the exposed secrets were hundreds of GitLab and GitHub tokens, Stripe, RSA private keys, OpenAI keys, AWS tokens, Slack and Discord webhooks, etc.
To mitigate the risks, the Escape researchers advise centralizing token management and rotating tokens regularly. Moreover, it’s possible to monitor token usage patterns, restrict token scope, allocate tokens to specific teams or services, and assign appropriate permissions to team members.
JANUARY
GitLab Status info: 4 incidents
🚨 Incidents that had a major impact – 2 incidents
⌛ Total time of partial service disruption – 13 hours 12 minutes
⚠️ Incidents that had a minor impact – 2 incidents
⌛ Total time of degraded performance – 223 hours 46 minutes
In January, GitLab users might face 2 major incidents causing over 13 hours of partial service disruption that GitLab experienced.
Moreover, there were 2 minor incidents that resulted in 223+ hours of degraded performance.
Possible file overwriting due to workspace creation flaw
On January 25th, 2024 GitLab released the fixes to address a security flaw, tracked as CVE-20240-402 with a CVSS score of 9.9, in its Community Edition and Enterprise Edition.
Using the vulnerability, bad actors could write files to arbitrary locations while creating a workspace.
“An issue has been discovered in GitLab CE/EE affecting all versions from 16.0 prior to 16.5.8, 16.6 prior to 16.6.6, 16.7 prior to 16.7.4, and 16.8 prior to 16.8.1 which allows an authenticated user to write files to arbitrary locations on the GitLab server while creating a workspace. This is a critical severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9).”
Also, in the January patch release, GitLab addressed a few other security flaws of medium severity:
- ReDoS in Cargo.toml blob viewer, tracked as CVE-2023-6159, with a CVSS of 6.5, which allowed an attacker to trigger a Regular Expression Denial of Service via a Cargo.toml containing maliciously crafted input.
- Arbitrary API PUT requests via HTML injection in user’s name, tracked as CVE-2023-5933, with a CVSS of 6.4.
- Disclosure of public email in Tags RSS Feed, tracked as CVE-2023-5612 with the CVSS of 5.3, which allowed to read the user email address via tags feed despite the fact that the visibility in the user profile was disabled.
- Non-member update of MR Assignees of owned MRs, tracked as CVE-2024-0456 with the CVSS of 4.3, which allowed an unauthorized threat actor to assign arbitrary users to MRs that they created within the project.
To mitigate the issues, GitLab strongly recommends its users who are running an affected version to upgrade their instance to the latest version as soon as possible.
The Hacker News / Help Net Security
More than 5K servers are vulnerable to assaults that use zero-click account takeover
Due to the critical flaw CVE-2023-1028, with a CVSS score of 10 of a maximum of 10!, over 5,379 internet-exposed GitLab instances were reported to be vulnerable to a zero-click account takeover flaw. Using the vulnerability, the threat actors can change the user’s password to GitLab and take control of the account by sending password reset emails under the attackers’ control.
According to Shadowserver reports, the most vulnerable GitLab servers were found in the USA with 964 ones, and Germany with 721 ones.
Source: Shadowsever reports (X)
On January 11th, 2024, 13 days prior, GitLab released patches for the impacted GitLab Community and Enterprise Edition versions 16.1 (prior to 15.1.5), 16.2 (prior to 16.2.8), 16.3 (prior to 16.3.6), 16.4 (prior to 16.4.4), 16.5 (prior to 16.5.6), 16.6 (prior to 16.6.4), and 16.7 (prior to 16.7.2).
Later GitLab advised its users to check where they are vulnerable to the issue, and if so, rotate all their credentials, API tokens, certificates, and other secrets. Moreover, it’s worth enabling 2FA on all the accounts together with security updates.
Bleeping Computer / The Register
Takeaway
Comparing year to year, it’s possible to confirm that cyberattacks are growing and hackers are eager to use any possible vulnerability or security flaw to access their victims’ critical data. Attackers try to do their best to target GitLab as it is a hub for hosting various types of diffrent organizations’ sensitive corporate data, such as API keys, or proprietary code, which open the doors for threat actors to further malicious actions. Among those, there can be compromising the breached GitLab user’s repositories, supply chain attacks, etc.
GitLab is a secure hosting service that instantly reacts to incidents… and in 2024, the service provider experienced over 90 incidents, including those that might lead to service disruption, totaling over 798+ hours (around 99 working days!), and partial disruption events – 44 incidents in 2024 with the summed-up time of over 585 hours of upset.
Moreover, GitLab always takes immediate actions to mitigate security flaws. However, there is still a shared responsibility model between the service provider and a GitLab user. It states that both GitLab and its users are responsible for the security of their data. From its side, GitLab does everything to help its users save their data, but let’s not forget that GitLab account data safety is the user’s duty. Thus, it’s important to implement security best practices, including updating GitLab instances should the GitLab’s advisory issued, implementing the principle of the least privilege, using vulnerability management, and backing up their critical DevOps and PM data.
GitProtect.io is a professional backup and DR tool for DevOps environments that can help GitLab admins build their backup & DR strategy within GitLab backup best practices, and meet security compliance regulations.
[FREE TRIAL] Ensure compliant GitLab backup and recovery with a 14-day trial🚀
[CUSTOM DEMO] Let’s talk about how backup & DR software for GitLab can help you mitigate the risks
