{"id":6661,"date":"2026-01-21T23:54:10","date_gmt":"2026-01-21T23:54:10","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=6661"},"modified":"2026-01-21T23:54:10","modified_gmt":"2026-01-21T23:54:10","slug":"gitlab-2fa-login-protection-bypass-lets-attackers-take-over-accounts","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=6661","title":{"rendered":"GitLab 2FA login protection bypass lets attackers take over accounts"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

A critical two-factor authentication bypass vulnerability in the Community and Enterprise editions of the GitLab application development platform has to be patched immediately, say experts.<\/p>\n

The hole is one of five vulnerabilities patched Wednesday as part of new versions of GitLab. Three are ranked High in severity, including the 2FA bypass issue, while the other two are ranked Medium in severity.<\/p>\n

GitLab says the 2FA hole, CVE-2026-0723<\/a>, if exploited on an unpatched system, could allow an individual with knowledge of a victim\u2019s ID credentials to bypass two-factor authentication by submitting forged device responses.<\/p>\n

It\u2019s this hole that has drawn the attention of experts, because of the implications.<\/p>\n

The goal of multifactor authentication is to protect login accounts with an extra verification step in case usernames and passwords are stolen. If a threat actor can access an account, they can do almost unlimited damage to IT systems.<\/p>\n

In the case of GitLab, if critical code is sitting in a developer\u2019s account, a threat actor could compromise it, notes David Shipley<\/a>, head of Canadian-based security awareness training firm Beauceron Security. If that code is to be used in software that can be downloaded or sold to other organizations, then inserted malware could be spread in a supply chain attack. The latest example, Shipley said, is the Shai-Hulud worm<\/a>, which is spreading because a developer\u2019s account in the npm registry was hacked.<\/p>\n

If the code contains cloud secrets, he added, the threat actor could gain access to cloud platforms like Azure, Amazon Web Service, or Google Cloud Platform.<\/p>\n

Discovery of the 2FA bypass hole \u201cis a reminder that these [security] controls are important,\u201d Shipley said in an interview. \u201cThey absolutely help reduce a number of risks: Brute force attacks, password spraying, and so forth. But they will never be infallible.<\/p>\n

\u201cThis is not the first time someone has found a clever way to get around 2FA challenges. We have a whole series of attacks around session cookie capture<\/a> which are also designed to defeat 2FA. So it\u2019s important to remember this when someone drops some Silver Bullet thinking that \u2018This magic solution solves it [authentication]\u2019 or \u2018That\u2019s the bad MFA. Here\u2019s the new MFA.\u2019 And I include [trusting only] Yubikeys,\u201d he said. \u201cYubikeys are amazing. They\u2019re the next generation of 2FA. But because they are made for humans, eventually they will have some flaws.\u201d<\/p>\n

Even if there weren\u2019t flaws in these controls, employees might be tricked into giving up credentials through social engineering, he added.<\/p>\n

It would be easier for an attacker to use techniques like phishing to collect user credentials rather than forge a device credential to exploit this particular 2FA bypass, said Johannes Ullrich<\/a>, dean of research at the SANS Institute. But, he added, once the attacker has access to valid passwords, they can log in to the GitLab server and perform actions on the source code \u2014 download it, alter it or delete it \u2014 just as a legitimate user would.<\/p>\n

What infosec leaders need to do<\/h2>\n

This is why Cybersecurity 101 \u2014 layered defense \u2014 is vital for identity and access management, Shipley said. That includes forcing employees to have long, unique login passwords, monitoring the network for unusual activity (for example, if someone gets in without an MFA challenge recorded) and, in case all fails, an incident response plan.<\/p>\n

MFA bypass vulnerabilities are very common, noted Ullrich. \u201cThe core problem is usually that MFA was added later to an existing product,\u201d he said, \u201cand some features may not properly check if MFA was successfully completed.\u201d<\/p>\n

When testing a multifactor authentication solution, infosec leaders should always verify that an application has not marked authentication as completed after the username and password were verified. Enabling MFA should not relax password requirements, he asserted. Users must still pick unique, secure passwords and use password managers to manage them. Secure passwords will mostly mitigate any MFA failures, Ullrich said.<\/p>\n

Any vulnerability found in GitLab is significant, he added. GitLab is typically used by organizations concerned enough about the confidentiality of their code that they want to run the platform on premises.\u00a0<\/p>\n

GitLab \u2018strongly\u2019 recommends upgrades<\/h2>\n

In describing the patches released Wednesday, GitLab said it \u201cstrongly\u201d recommends all self managed GitLab installations be upgraded to one of the three new versions (18.8.2, 18.7.2, 18.6.4) for GitLab Community Edition (CE) and Enterprise Edition (EE). Those using GitLab.com or GitLab Dedicated \u2013\u00a0 a single tenant software-as-a-service version \u2013\u00a0 don\u2019t have to take any action.<\/p>\n

The other vulnerabilities fixed in Wednesday\u2019s updates are:<\/p>\n

CVE-2025-13927<\/a>, a denial of service issue in Jira Connect integration. If exploited on an unpatched system, it could allow an unauthenticated user to create a denial of service condition by sending crafted requests with malformed authentication data. It carries a CVSS severity score of 7.5;<\/p>\n

CVE-2025-13928<\/a>, an\u00a0incorrect authorization issue. If exploited on an unpatched system, it could allow an unauthenticated user to cause a denial of service condition by exploiting incorrect authorization validation in API endpoints.\u00a0 It carries a CVSS severity score of 7.5;<\/p>\n

CVE-2025-13335<\/a>,\u00a0an infinite loop issue in Wiki redirects. Under certain circumstances, this hole could allow an authenticated user to create a denial of service condition by configuring malformed Wiki documents that bypass cycle detection. It has a CVSS score of 6.5;<\/p>\n

CVE-2026-1102<\/a>\u00a0\u2013 a denial of service issue in an API endpoint that could allow an unauthenticated user to create a denial of service condition by sending repeated malformed SSH authentication requests. It has a CVSS score of 5.3.<\/p>\n

In keeping with standard GitLab practice, details of the security vulnerabilities will be made public on an\u00a0issue tracker<\/a>\u00a030 days after the release in which they were patched.\u00a0<\/p>\n

The new versions also include bug fixes, some of which, GitLab said, may include database migrations. In cases of single-node instances, a patch will cause downtime during the upgrade. In the case of multi-node instances, admins who follow proper GitLab zero-downtime upgrade procedures can apply a patch without downtime.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

A critical two-factor authentication bypass vulnerability in the Community and Enterprise editions of the GitLab application development platform has to be patched immediately, say experts. The hole is one of five vulnerabilities patched Wednesday as part of new versions of GitLab. Three are ranked High in severity, including the 2FA bypass issue, while the other […]<\/p>\n","protected":false},"author":0,"featured_media":6662,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-6661","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6661"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6661"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6661\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/6662"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6661"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6661"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6661"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}